Goal

Refactor the post-quantum integration tests to use the in-memory TLS harness.

Why

ML-DSA support was made publicly available in s2n-tls (#5257), but the initial integration testing was intentionally temporary and hacky due to tooling and provider limitations. As noted in #5308, we should follow through by implementing standard integration tests using the in-memory test pair, preferably using a non–AWS-LC provider.

There are still blockers to adding ML-DSA coverage to the integrationv2 test matrix:

• The OQS + OpenSSL 1.1.1 builds in CI predate ML-DSA
• AWS-LC does not currently support ML-DSA via libssl/bssl
• OpenSSL 3.5 is the preferred non–AWS-LC provider for PQ testing, but is not yet available in our CodeBuild images or Nix setup (for integV2).

Given these constraints and our effort to move integration tests to Rust, the in-memory integration harness is currently the best way to provide PQ integration test coverage.

How

• Removed required_capability_async as it is no longer needed, instead the existing synchronous required_capability helper can be used to drive the in-memory test pair.
• Migrated PQ tests to use the in-memory TlsConnPair harness, avoiding Tokio/OpenSSL socket wiring
• Modified client/server setup for ML-DSA, ML-KEM, and pure ML-KEM cases while preserving coverage of:
  • client vs server roles
  • hybrid vs pure PQ negotiation
  • negotiated signature algorithms and KEM groups

Callouts

• The in-memory harness defaults hostname verification to "localhost". The RFC-derived ML-DSA certificate uses "LAMPS WG" as its Common Name, so when the s2n client reaches CN-based hostname validation, "LAMPS WG" is rejected by the default verifier (expecting "localhost"), causing S2N_ERR_CERT_UNTRUSTED. A custom verify-host callback is installed to treat "LAMPS WG" as the expected server name.
• In the pure MLKEM tests, capability gating differs by role: when s2n acts as a server, it must sign CertificateVerify with the ML-DSA private key, so the test requires MLKEM + MLDSA. When s2n acts as a client, the test focuses on PQ group negotiation, so MLKEM alone is sufficient.

Testing

• Existing PQ integration tests were updated and continue to pass when the relevant capabilities are supported
• Tests correctly fail (or are skipped) when required PQ capabilities are unavailable

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.