TestKit.Xunit: implement the async dispose chain so a derived DisposeAsync no longer leaks the ActorSystem; de-flake StreamRefsSpec

[Aaronontheweb]

Stacked on #8558.

What changes

• Akka.TestKit.Xunit.TestKit implements the async lifecycle. It gains virtual InitializeAsync() and virtual DisposeAsync(). Both public entry points run the same chain, Dispose(bool) with AfterAll and any override inside it, and differ only in how they terminate the ActorSystem: Dispose() blocks on Shutdown(), DisposeAsync() awaits ShutdownAsync(). A derived test class that overrides DisposeAsync and chains to the base no longer skips teardown. This is stalled PR fix: implement IAsyncLifetime on Akka.TestKit.Xunit (v3) to stop ActorSystem leaks (#8191) #8217 ported to dev, minus its TestKitBase hunk, which landed in Add TestKitBase.ShutdownAsync and adopt it in StressSpec churn teardown #8499. Its regression test, Bugfix8191Spec, comes with it. Extend-only.
• Four derived classes that declared their own DisposeAsync or InitializeAsync now use override and chain to the base. BREAKING_CHANGES_V1.6.md records the compile-warning risk for user code in the same shape.
• StreamRefsSpec overrides DisposeAsync to shut the remote system down asynchronously and then chain to the base, binds its remote system to port 0 instead of a probed port, and its remoting fact is now async, gated on WatchTermination so the test waits for the stream to finish rather than for a clock, with a dilated 15 s budget on all four remote waits.

Why

Build 131174 failed SinkRef_must_receive_elements_via_remoting after a flat 3 s wait, on a PR that changed one package version. The stream-ref handshake is correct and matches Pekko; no element can leave before the partner is watched. The test was fragile for two reasons the analysis established:

• Issue Akka.TestKit.Xunit (v3): base.DisposeAsync() unreachable from derived IAsyncLifetime — silently leaks ActorSystems #8191. xUnit v3 calls IAsyncDisposable.DisposeAsync() in preference to Dispose() when a class has both. StreamRefsSpec had a no-op DisposeAsync, so its teardown never ran and every fact leaked two remoting-enabled ActorSystems, each keeping DotNetty threads and a 100 Hz scheduler on the shared thread pool. Twenty-eight leaked systems by the end of the class.
• The test blocked its calling thread with .GetAwaiter().GetResult() while the handshake needed about ten thread-pool dispatches, on a 2-vCPU agent whose pool floor is two. That is the shape every other thread-pool flake this week shared.

No thread pool setting is changed. Two product items from the analysis are not in this PR and are worth their own issues: SinkRefImpl lacks Pekko's grace period on early partner termination, and ActorMaterializerImpl.ActorOf blocks on a task result. A separate small PR fixes a TestKit config key that never took effect.

How it was checked

Akka.TestKit.Xunit and Akka.Streams.Tests build with warnings as errors, as do the four other touched test projects. Akka.API.Tests: 18 passed, no approval change, since the v3 TestKit has no approval file and TestKitBase is untouched. StreamRefsSpec run five times: 16 passed, 1 skipped, every time. Bugfix8191Spec, all of Akka.TestKit.Xunit.Tests (33), and Akka.TestKit.Tests (220) pass.

Second commit: the touched files move to the async TestKit API

Per the maintainer's rule that a touched test file migrates in the same PR: the fourteen remaining facts in StreamRefsSpec are async Task and await ExpectMsgAsync, ExpectNoMsgAsync, and the stream-completion tasks (three .Wait(8s) calls become awaits with the same timeout). One fact each in the DI BugFixSpec and Bugfix8144Spec migrate the same way, since this PR already touched them for the override. No assertion or skip marker changes. A grep for the synchronous forms over StreamRefsSpec returns nothing. StreamRefsSpec run three times after the migration: 16 passed, 1 skipped, each time.

Third commit: what the adversarial review found

• Seven blocking stream-probe calls were still inside async facts, each a blocking wait on its async twin: EnsureSubscription, ExpectNext, ExpectNextN, ExpectError. Three more turned up on a full scan, ExpectCancellation twice and ExpectRequest once. All ten now await the async form.
• Two thread sleeps become dilated task delays. There is no event to wait on there: the remote side's 500 ms subscription timeout fires with nothing materialized locally, so the wait is a real clock wait, now dilated instead of flat.
• The spec's log level goes back to INFO. Debug logging on a remoting plus streams spec loads the thread pool this PR blames.
• The DI BugFixSpec still shut its DI-managed system down with a blocking call in AfterAll; it now overrides DisposeAsync, shuts that system down asynchronously, and chains to the base, the same shape StreamRefsSpec uses.

StreamRefsSpec run three times: 16 passed, 1 skipped, each time. BugFixSpec passes. Both projects build with warnings as errors. The grep for blocking probe and TestKit calls on both files returns only comments.

Fourth commit: the lease spec joins the chain

ClusterShardingLeaseSpec on #8558 declares its own InitializeAsync and DisposeAsync through IAsyncLifetime, and this PR makes both virtual on the TestKit, so whichever landed second would have failed the build with two hidden-member errors. This PR is now stacked on #8558, and its fourth commit converts that spec the way the other derived classes were converted: InitializeAsync becomes an override that chains to the base, the dispose bridge goes away because the base now runs the synchronous dispose and the async shutdown itself, and the interface declaration is dropped. The sharding test project builds with warnings as errors, which is the build that would have broken, and the lease spec passes 15 of 15 twice.

Fifth commit: one flag, one chain

The maintainer asked why the TestKit carried three flags. Two predated this PR, and one of those was already redundant since it was never cleared; the third was a mode switch this PR added so DisposeAsync could run the virtual Dispose(bool) while suppressing the blocking Shutdown() inside it. The chain is now the smallest correct shape: Dispose(bool) runs AfterAll() and nothing else, so it is the one place overriders hook; a single _disposed flag is checked and set at the top of each public entry point; Dispose() runs the chain then Shutdown() in a finally, DisposeAsync() runs it then await ShutdownAsync() in a finally; a second call by either route, including Dispose() after DisposeAsync(), is a no-op.

What changes for an overrider: base.Dispose(disposing) no longer terminates the system; the public entry point does, after the whole chain. Every Dispose(bool) override in this repo is on a stream or stage type, not on this TestKit, and the derived DisposeAsync overrides in StreamRefsSpec and the DI BugFixSpec shut their own second system down and then chain to base, which is unaffected. A new fact in Bugfix8191Spec proves the chain runs once when Dispose() follows DisposeAsync().

Checked: Akka.TestKit.Xunit builds with warnings as errors; Akka.TestKit.Xunit.Tests 34 passed; Akka.TestKit.Tests 331 passed, 1 skipped; StreamRefsSpec 16 passed, 1 skipped; Akka.API.Tests 18 passed, no approval diff.

[Aaronontheweb]

LGTM

[Aaronontheweb]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).