Avoid building SslStreamCertificateContexts inside Listener in Quic tests

[rzikm]

Summary

Related to #133645.

This change prevents QUIC tests from repeatedly constructing certificate contexts from leaf certificates when the issuer material is already known:

• Cache one offline SslStreamCertificateContext for the default server certificate and one for the default client certificate at the QuicTestCollection fixture lifetime.
• Reuse those contexts across tests while continuing to give individual test instances disposable certificate clones for assertions.
• Explicitly clear the cached server context in tests that provide a different certificate or a certificate-selection callback, preserving the intended SslServerAuthenticationOptions precedence.
• Keep leaf/selection-callback setup in tests whose purpose is to exercise those client-certificate source APIs.
• Build and pass an offline server context containing the generated issuer chain in ConnectWithCertificateForLoopbackIP_IndicatesExpectedError.

The temporary certificate-provisioning experiment, selectors, standalone chain probes, and runbook have been removed.

Motivation

On Windows with Schannel, a leaf-only QUIC credential configuration can cause MsQuicConfiguration to build an SslStreamCertificateContext with online issuer discovery before native credential acquisition. Controlled responder delays demonstrated that this managed context construction can perform two sequential AIA downloads and exceed the test's ten-second handshake timeout.

After the AIA-related runtime changes in #134585, native MsQuic credential acquisition is cache-only, but the preceding managed context construction can still perform issuer discovery. In an isolated server-credential control with six-second AIA response delays:

• Leaf-only configuration took 12.231 seconds and issued two AIA requests.
• A prebuilt offline server context took 44 ms and issued no AIA requests.

The same delayed-AIA control caused the leaf-only QUIC handshake to time out, while the prebuilt-context configuration connected without AIA requests. This establishes the blocking mechanism under controlled fault injection; it does not prove that every historical failure had the same external delay source.

Behavioral invariants

The loopback certificate test retains:

• TargetHost = "localhost".
• Both 127.0.0.1 and ::1 IP SANs.
• The expected DNS mismatch for the badhost certificate.
• Subject, issuer, and name-mismatch assertions.
• X509RevocationMode.NoCheck client semantics and the existing ten-second handshake deadline.

No retry, timeout increase, validation bypass, or trusted-root change is introduced.

Validation

After rebasing onto main at 122c28feba4:

.\dotnet.cmd build src\libraries\System.Net.Quic\tests\FunctionalTests\System.Net.Quic.Functional.Tests.csproj /t:Test /p:Outerloop=true

Result: 479 total, 478 passed, 1 expected platform skip, 0 failures/errors. No unobserved exceptions were reported.

Note

This PR description was generated with GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 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: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

[rzikm]

/azp run runtime-libraries-coreclr outerloop

[azure-pipelines]

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

[dotnet-policy-service]

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

[ManickaP]

Hope this helps!

[rzikm]

/ba-g SmtpClientTlsTest failures are known and unrelated