feat(s2n-quic): allow s2n-quic to use s2n-tls on Windows with MinGW

[boquan-fang]

Release Summary:

Allow s2n-quic to build and tests with s2n-tls on Windows as its TLS backend. s2n-quic running on Windows GNU/MinGW toolchain to use s2n-tls as its backend TLS provider by default.

Resolved issues:

related to aws/s2n-tls#4018

Description of changes:

s2n-tls v0.3.40 allows s2n-tls to work on Windows with MinGW toolchain. This PR allows s2n-quic to use s2n-tls as its TLS backend with MinGW toolchain.

The user use provider-tls-s2n and provider-tls-rustls to override TLS backend with either s2n-tls or rustls. If those features are not enabled, then Rustls is the default TLS backend for Windows and s2n-tls is default for Unix and Linux. See changes in https://github.com/aws/s2n-quic/pull/3153/changes#diff-6b8d5705ae18f0ed58dd7a327da48d641287fbc8739baeabb146f734d1e6b16a for details.

New build.rs + s2n_tls_provider / boringssl cfgs. This PR adds a build script to s2n-quic-tests that evaluates the target once and emits two named cfgs describing which optional dependency is available rather than which platform we're on. s2n_tls_provider replaces the any(unix, all(target_os = "windows", target_env = "gnu")) predicate that had been copy-pasted across 10 sites, and boringssl replaces the quiche gate not(all(target_os = "windows", not(target_env = "msvc"))). The gates now read as intent ("this test needs s2n-tls") instead of a platform matrix, and there's a single source of truth to update if the support surface ever changes. The build script also registers both names via cargo::rustc-check-cfg so the unexpected_cfgs lint stays quiet under -D warnings.

Call-outs:

1. After this PR is merged in, I will need to update the doc of s2n-quic to indicate that it can work with s2n-tls on Windows.
2. I excludes dc crate from this PR.
3. I will make s2n-quic running on Windows GNU/MinGW toolchain to use s2n-tls as its backend TLS provider by default.
   The default TLS provider:

Platform	Default TLS Provider
Unix and Linux	s2n-tls
Windows with MinGW toolchian	s2n-tls
Windows with MSVC	Rustls

Testing:

I added a new job in ci.yml to run all tests for MinGW Windows: https://github.com/aws/s2n-quic/actions/runs/29284288996/job/86932902570?pr=3153.

The CI set up is very similar to the one that I added for s2n-tls: https://github.com/aws/s2n-tls/blob/main/.github/workflows/ci_windows.yml.

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

[maddeleine]

Do we have a user who we think will pick up this feature? I'm glad to know this works, but I'm just not really sure what the usecase is here. Is there someone right now who is waiting to s2n-quic with s2n-tls as a backend on mingw? This wasn't in the original issue(aws/s2n-tls#4018) so I'm not sure why we're pushing for it.

[WesleyRosenblum]

Can you check the existing provider-tls-s2n feature, I believe the intension of that was to allow for overriding the TLS implementation used, versus using the default (which is provider-tls-default, turned on by default)

[boquan-fang]

@WesleyRosenblum Yes, we should reuse the existing provider-tls-s2n and provider-tls-rustls flag for users to set their TLS backend. With this code change, the s2n-tls will be used regardless if the user import s2n-tls with the provider-tls-s2n feature. If they don't specify any features, then Rustls will be used by default for Windows users and s2n-tls will be used by Linux users. Replying to #3153 (comment).

[boquan-fang]

I will make s2n-quic running on Windows GNU/MinGW toolchain to use s2n-tls as its backend TLS provider by default.