[Tsavorite] Do not wait for a stopped size tracker in NeedToWaitForClose during AOF replay - #2175

Root Cause

During AOF replay the LogSizeTracker has not been started yet. NeedToWaitForClose still asks it to evict: when IsBeyondSizeLimitAndCanEvict(addingPage: true) is true it calls Signal() and returns true, so TryAllocateRetryNow retries. If the log heap alone is over budget and the page count is below MaxAllocatedPageCount, IssueShiftAddress does not shift HeadAddress either, and the retry loop never ends. Recovery hangs before the server binds its port. It needs objects (heap) over budget, so string-only data is not affected.

#1932 added the !logSizeTracker.IsRunning guard to IssueShiftAddress for this reason; NeedToWaitForClose was left without it.

Description of Change

libs/storage/Tsavorite/cs/src/core/Allocator/AllocatorBase.cs: NeedToWaitForClose returns false when the size tracker is not running, as IssueShiftAddress already does. With a running tracker nothing changes.

Tests

• RespAdminCommandsTests.SeAofRecoverObjectsOverHeapBudgetTest: 2,000 hashes of 2 KB on a lowMemory server with AOF, unclean dispose, then recover. Like SeSaveRecoverMultipleKeysTest, it calls server.Start() directly, so a regression shows up as a hang (without the change, --blame-hang-timeout 3m aborts it); with the change, all values are recovered.
• SeAofRecover* and SeSaveRecover* (19 passed, 2 skipped), Tsavorite.test.recovery (246 passed), Tsavorite.test.hlog (596 passed), Garnet.test.extensions (536 passed), net10.0 Release on Windows, on current main.
• The repro in AOF recovery hangs when objects put the log heap over the size tracker budget #2174 (30,000 HSET, docker kill, docker start) recovers in about 2 seconds with all keys.

Issues Fixed

Fixes #2174