Honour certificate verification mode when custom trust roots are set (TransportServices)

[dmonagle]

Fixes #184.

Motivation

With trustRoots: .certificates(...), the TransportServices transports install a verify block that anchors the custom roots and then calls SecTrustEvaluateAsyncWithError on the trust exactly as Network.framework configured it — with the default SSL policy, which includes hostname matching. The configured CertificateVerification mode is never consulted there:

• .noHostnameVerification behaves like full verification: any certificate whose SANs don't cover the dialled endpoint is rejected (errSSLBadCert), even though the chain validates against the custom roots. This breaks private-CA deployments whose certs deliberately carry no DNS/IP SANs, and peers dialled by IP address. The identical configuration works with the Posix transport, where the mode maps to NIOSSL's certificateVerification = .noHostnameVerification.
• .noVerification still installs the evaluating block and can fail the handshake despite verification being explicitly disabled.

Modifications

The verify block now receives the verification mode and whether it is evaluating server or client certificates:

• .noHostnameVerification: the trust is re-policied with SecPolicyCreateSSL(<role>, nil) before evaluation — chain validation against the custom anchors is unchanged, hostname matching is skipped.
• .noVerification: no verify block is installed (the callers already set sec_protocol_options_set_peer_authentication_required(false) for this mode), matching NIOSSL semantics.
• .fullVerification: behaviour unchanged.

Result

.noHostnameVerification + custom trust roots connects when the chain is valid but the hostname doesn't match, on both client and server TransportServices transports, matching the Posix transport.

New regression test (testClientNoHostnameVerificationIgnoresHostname) covers all client/server transport combinations; without the source change the two TransportServices-client cases fail with NWError.tls(-9808). Existing TLS suites pass (HTTP2TransportTLSEnabledTests, TLSConfigurationTests).

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: dmonagle / name: David Monagle (9001353)

[glbrntt]

Thank you!

[dmonagle]

The two failing jobs (Linux nightly-main / nightly-next) reproduce on main — the nightly toolchain's SwiftPM now errors on the Documentation.docc directories ("found 1 file(s) which are unhandled; explicitly declare them as resources or exclude from the target") for four targets. Unrelated to this change; all release-toolchain jobs pass.