[No review] Add diagnostics for HTTP/3 request reuse test timeouts

[rzikm]

Summary

Add instrumentation to investigate the factory timeout in SocketsHttpHandler_DiagnosticsTest_Http3.SendAsync_ReuseRequestInHandler_ResetsHeadersForEachReuse, tracked by #132085.

The test observes its client task only after three server transactions complete. A factory timeout currently does not tell us whether that task faulted or which loopback operation is pending. This change records:

• Opt-in HTTP/3 connection acceptance, control-stream/settings exchange, request stream IDs, GOAWAY/response writes, disconnect handling, and disposal phases.
• Each request reuse and intermediate response disposal, plus the client task's status and original exception at test completion or failure.
• Request-handling exceptions before connection disposal, so a subsequent cleanup failure does not erase them from the diagnostic output.

Messages are timestamped and buffered in a thread-safe queue, then written to xUnit output outside the factory callback. A callback that outlives the factory timeout therefore does not write to a finished test's output helper. Other loopback users leave logging disabled.

This is instrumentation only, not a claimed fix or root-cause diagnosis. It preserves the existing header assertions, request instance reuse, statuses, connection sequencing, GOAWAY/shutdown behavior, and timeout budgets. It does not add retries, cancellation changes, or quarantines.

Validation

Windows x64, locally built .NET 11, libraries Debug / CoreCLR Release:

• build.cmd clr+libs -rc release: passed, zero warnings/errors.
• All four request-reuse variants: 4 passed, no skips. The HTTP/3 result XML contains all three connection/disconnect/disposal lifecycles and all three header-check phases.
• Full System.Net.Http.Functional.Tests inner-loop suite: 5,476 total; 5,428 passed, 48 skipped, zero failures.
• Isolated negative control: configured an HTTP proxy only in the test process to force an early HTTP/3 client failure. The test still failed with the original approximately 72-second factory TimeoutException, while its output exposed Client task status: Faulted, the underlying HttpRequestException and stack, and the pending connection-accept phase. No fault injection is included in the patch.

The original Alpine 3.24/Linux-musl failure was not reproduced locally. These Windows results validate the added instrumentation, not a fix for that failure.

Related to #132085; intentionally left open for the underlying investigation.

Note

This PR was prepared with GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[Copilot]

Copilot review overview

🟢 Approval recommended

The instrumentation is opt-in, thread-safe, and preserves existing request and connection behavior.

Review effort: Lite
Findings: None

What changed in this PR

Adds opt-in diagnostics for HTTP/3 request-reuse timeout investigation without changing test behavior.

Changes:

• Buffers timestamped client/server diagnostics safely.
• Logs HTTP/3 connection, stream, response, disconnect, and disposal phases.
• Captures client task status and exceptions on failure.

File	Description
DiagnosticsTests.cs	Adds request and client-task diagnostics.
Http3LoopbackServer.cs	Adds optional logging and exception diagnostics.
Http3LoopbackConnection.cs	Logs HTTP/3 lifecycle operations.

[rzikm]

/azp run runtime

Note

CI rerun requested by GitHub Copilot at the author's request to investigate the intermittent HTTP/3 timeout without merging this PR.

[azure-pipelines]

No pipelines are associated with this pull request.

[rzikm]

/azp run runtime

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[rzikm]

/azp run runtime

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[rzikm]

/azp run runtime

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[rzikm]

/azp run runtime

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).