Tighten up SetupFixtures and move TestBase to Tsavorite; handle cancellation race condition in maintenance loops - #2162

Fixes #2160
Fixes #2165

Test-infrastructure layering and fixture cleanup, plus a pre-existing product race found along the way. Relates to #2161 (closed by #2159, whose #if GARNET_TEST_UTILS guard this replaces).

1. TestBase moves into Tsavorite

Tsavorite.test.csproj link-compiled test/standalone/Garnet.test/TestBase.cs. The Tsavorite tree therefore could not be built on its own, and #2151's edit to that shared file broke Build Tsavorite on main.

• TestBase now lives at libs/storage/Tsavorite/cs/test/TestBase.cs in namespace Tsavorite.test; 85 Tsavorite files drop using Garnet.test;.
• Garnet.test and Garnet.test.cluster take a ProjectReference on Tsavorite.test instead of link-compiling the file.
• Garnet test projects resolve the type through one <Using Include="Tsavorite.test.TestBase" Alias="TestBase" /> in each of the two test/*/Directory.Build.props. The alias imports only that type, so Tsavorite.test.TestUtils cannot collide with Garnet.test.TestUtils.
• No <Compile Include> or <ProjectReference> under libs/storage/Tsavorite/ escapes the tree any more.

2. SetUpFixtures tightened

TestBase.cs also declared a global-namespace GlobalUnhandledExceptionHandling [SetUpFixture]. NUnit discovers a SetUpFixture only in the assembly that compiles it, so that handler would have been silently lost once the file moved behind a project reference.

It is now TestBase.InstallUnhandledExceptionHandlers(), invoked from one TestProjectSetup per assembly — Tsavorite.test, Garnet.test, Garnet.test.cluster, exactly the three that had it before. The two Garnet fixtures also keep the eager port-slot resolution #2151 introduced.

Two consequences:

• GARNET_TEST_UTILS is removed from both csprojs; nothing needs it now.
• The ci.yml tsavorite path filter no longer needs a TestBase.cs entry — libs/storage/Tsavorite/** covers it by construction rather than by a rule someone must remember to keep in sync.

3. Port slot probe answered the wrong question twice

ArePortsFree decides whether GARNET_TEST_PORT_SLOT=auto may claim a slot. Both holes let it report an occupied slot free, so auto committed to a doomed slot instead of moving to the next one.

• Probe all standalone assignments before claiming a test port slot #2160 — it probed 1 of the 10 TestPortAssignment values plus the cluster band. Ports are now enumerated from the enum itself (SlotPorts), so a new assignment is covered without editing the probe.
• auto test port slot probe only checks loopback, so a stranded non-loopback listener reads as free #2165 — it bound IPAddress.Loopback only, so a listener on any other address was invisible. Both wildcards are now probed, with ExclusiveAddressUse = true.

The exclusive flag is load-bearing rather than incidental. TcpListener.ExclusiveAddressUse defaults to false, and under default options a wildcard bind does not conflict with a specific-address listener — so probing both wildcards without it reports 127.0.0.1 free, a strict regression on the one case the loopback probe did catch.

Row 3 is the widest hole and is not what #2165 was filed about: ClusterConfigTests and ClusterTestContext bind IPAddress.Any, so a stranded cluster node — the listener most likely to survive a crashed run — holds the port on every interface, and the loopback probe read it as free. Socket.OSSupportsIPv6 gates the second bind so a host with IPv6 disabled reads free rather than refusing all seven slots. Only auto probes, so CI pays nothing.

4. Cancellation race in the maintenance and gossip loops

Pre-existing on main and unrelated to the above; it surfaced here as a one-off CI flake after the main merge. This is the residue of a bug #2139 already mostly fixed — before that PR each loop wrapped its whole body in a single terminal catch, so any cycle fault disabled that task for the lifetime of the process. #2139 added the per-cycle guard and is not in question; what remains is the narrow window where the guard itself declines.

Both guards were exception filters: catch (Exception) when (!token.IsCancellationRequested). If cancellation arrives between the cycle throwing and the filter being evaluated, the filter declines, and because the exception is not an OperationCanceledException it skips the cancellation handler as well and is reported as terminal — LogCritical(… "The task won't be resumed.") in StoreWrapper.RunMaintenanceLoopAsync, LogWarning("GossipMain terminated with error …") in ClusterManager.GossipMainAsync.

Both now classify inside the handler rather than in the filter, so a cycle failure is never handed to outer handlers that recognize cancellation only by exception type.

MaintenanceLoopTests.ACycleFailingAsShutdownBeginsIsNotLoggedAsTerminal cancels inside the cycle and then throws, making the window deterministic; it fails against the old shape with a Critical entry while the four existing tests pass. GossipMainAsync gets no equivalent test: it has no seam for "fail exactly as cancellation lands", and the only way to build one fights ExceptionInjectionHelper's shutdown parking suspension, which exists because parking across shutdown hangs the test process.

Validation

Extraction check: libs/storage/Tsavorite/ copied out with only the repo-root build files it resolves upward (Directory.Build.props, Directory.Packages.props, Version.props, .editorconfig, Garnet.snk) and no test/ directory present. Those five are shared infrastructure that Tsavorite.core already required; the TestBase.cs link was the only source dependency.