Fix SslStream/QUIC server exit hang; re-enable handshake scenarios (Wave A) — closes #2140 partially

[LoopedBard3]

Fixes the root cause behind aspnet#2140 (and aspnet#2139) and re-enables the SslStream + QUIC handshake scenarios in CI-02. Read-write matrices stay gated for a follow-up after a few clean runs.

Why the scenarios were disabled

aspnet#2139 (Jan 12 2026) added && false to every condition in build/sslstream-scenarios.yml because the benchmark app "does not seem to be exiting properly, causing follow-up test runs to timeout." aspnet#2140 has tracked the re-enable since.

Actual root cause

Crank's Linux agent stops jobs with SIGTERM first (5 s grace) then SIGINT — see dotnet/crank src/Microsoft.Crank.Agent/Startup.cs. BenchmarkApp.RunAsyncInternal only registered Console.CancelKeyPress (catches SIGINT, not SIGTERM). When SIGTERM arrived:

• GlobalCts.Cancel never fired,
• the accept loop kept blocking in AcceptAsync,
• in-flight Task.Run-ed TLS/QUIC connection processors never observed cancellation,
• the .NET runtime's default SIGTERM behavior terminated the process after a brief ProcessExit window,
• but in-flight SslStream close_notify writes and QUIC connection drains could leave the listen socket / OS port stranded for the next benchmark run — matching the observed "follow-up test timeout" symptom.

Fix (three layers)

1. BenchmarkApp now registers PosixSignalRegistration for SIGTERM and SIGQUIT in addition to Console.CancelKeyPress. GlobalCts.Cancel runs on every shutdown signal crank can send. PosixSignalRegistration.Create is supported on Windows (maps to SetConsoleCtrlHandler), so the existing Ctrl+C path is unchanged.

2. BenchmarkApp wraps RunBenchmarkAsync with a 15 s hard shutdown deadline that fires after cancellation. If disposal stalls (stuck SslStream close_notify, QuicConnection drain, etc.) Environment.Exit(0) guarantees we release the port before crank's SIGKILL fallback fires.

3. BenchmarkServer now tracks per-accepted-connection Task.Run handles in a ConcurrentDictionary and drains them with a 10 s timeout before the await using listener disposes, so per-connection disposal can't race the listener teardown.

The two timeouts are intentionally tiered: drain (10 s) < hard exit (15 s) < crank SIGKILL fallback. The drain is best-effort and logs a warning when it expires.

Wave A re-enable (this PR)

build/sslstream-scenarios.yml:

• Line 127: SslStream Handshake matrix — && false removed.
• Line 148: QUIC Handshake matrix — && false removed.
• Lines 172, 195: SslStream / QUIC read-write matrices — left gated for now.

Existing Math.round(Date.now() / 43200000) % 2 == 0 half-day modulo is preserved on all four — re-enabled scenarios still run on alternate 12 h ticks.

10 publishes added back. Expected SslStream gold-lin job duration: ≈ 10–15 min on active ticks vs ≈ 2.3 min on off-ticks (vs ≈ 2.3 min today on every tick).

Wave B (follow-up)

After 2–3 clean CI-02 runs where the SslStream job finishes cleanly and no downstream gold-lin job times out, a follow-up PR will remove && false from lines 172 and 195 to bring back the 56 read-write publishes.

Validation done locally

• Built all four projects: SslStreamServer, SslStreamClient, QuicServer, QuicClient — succeeded.
• Started SslStreamServer on Windows, hit it with SslStreamClient (ReadWrite, 10 s warmup + 10 s duration) — clean run, metrics reported, port released after process termination.
• PosixSignalRegistration.Create(PosixSignal.SIGTERM, ...) confirmed to be a no-throw on Windows (server progressed past it at startup).
• Linux SIGTERM behavior can't be locally reproduced from a Windows worktree; the fix is logically grounded in the crank stop sequence + a source-side audit of the cancellation path.

Closes / refs

• Partially addresses Reenable SSLStream tests aspnet/Benchmarks#2140 (handshake scenarios). Wave B follow-up will fully close it.
• Reverts the effective state of Temporarily disable the SslStream benchmark runs aspnet/Benchmarks#2139 for the handshake matrices.