crypto: add rustls TLS foundation alongside openssl - #36085

I'll post the QA LLM review verbatim, hope that's ok:

Finding 1 (MEDIUM): make_tls_rustls drops the system/default CA trust store, so verify-full/verify-ca without an explicit CA will fail every connection

File: src/tls-util/src/lib.rs (make_tls_rustls, root-store construction)

The openssl make_tls builds its connector with
SslConnector::builder(SslMethod::tls_client()), which calls
set_default_verify_paths() internally and therefore trusts the process/system
default CA bundle. In verify-full (or verify-ca) mode with no explicit
sslrootcert, a server presenting a publicly/system-trusted certificate
verifies successfully. This matches libpq: with no ~/.postgresql/root.crt,
libpq falls back to the system CA store.

make_tls_rustls instead starts from rustls::RootCertStore::empty() and only
ever add()s certificates from config.get_ssl_root_cert(). There is no
rustls-native-certs / webpki-roots fallback (confirmed: neither crate is a
workspace dependency). So when verify_mode == true and no CA was supplied, the
root store is empty and the default WebPkiServerVerifier rejects every
server certificate — the TLS handshake can never succeed.

This is reachable via a real, user-configurable path. For CREATE CONNECTION ... TO POSTGRES, src/sql/.../ddl/connection.rs:445-457 maps SSL MODE 'verify-full' / 'verify-ca' to SslMode::VerifyFull / VerifyCa and, unlike
the SQL Server path, does not require SSL CERTIFICATE AUTHORITY
(tls_root_cert may be None). That config flows through
storage-types/connections.rs → mz-postgres-util → make_tls today. When
#36087 swaps that call to make_tls_rustls, any such connection that relied on
system/public CA trust silently starts failing at handshake time (source
ingestion / CSR outage), with no test to catch it (testdrive PG fixtures always
pin an explicit CA, and CI has no publicly-trusted-cert server).

It is fail-closed (a broken connection, not a verification bypass), so this is an
availability/correctness regression rather than a security hole. But it defeats
the function's stated contract of being "the rustls equivalent of make_tls",
and — unlike the related hostname deviation — it is not tracked anywhere
(see the note below).

Suggested fix: seed the root store from the platform trust store before
adding the user CA, matching openssl's set_default_verify_paths(). e.g. add
rustls-native-certs and, when verify_mode, load
rustls_native_certs::load_native_certs() into root_store in addition to any
sslrootcert entries (or fall back to webpki-roots). Add a regression case for
verify-full/verify-ca with no explicit CA against a system-trusted endpoint.

Related, already-tracked: verify-ca collapses into verify-full

For verify-ca (and require+CA), openssl uses (PEER, verify_hostname=false)
— it validates the chain but skips the hostname. make_tls_rustls folds both
VerifyCa and VerifyFull into verify_mode = true and uses rustls's standard
verifier, which always checks the hostname. So verify-ca behaves like
verify-full (stricter than libpq), breaking connections whose cert name does
not match the connection host (e.g. connecting by IP or internal name).

This deviation is already known and tracked in Linear SEC-192 ("rustls's
standard verifier always checks the hostname, so sslmode=verify-ca currently
behaves like verify-full ... Either add a custom verifier that skips the server
name check or document the stricter behavior as intended"), so I am not
re-reporting it — noting it only because the same root-store construction is
where both the tracked hostname issue and the untracked system-CA issue in
Finding 1 live, and both should be fixed together when the verifier is reworked.

Finding 2 (LOW): rustls client stream reports no channel binding, dropping SCRAM-SHA-256-PLUS

File: src/tls-util/src/lib.rs — RustlsTlsStream::channel_binding returns
ChannelBinding::none().

The openssl path (postgres-openssl) supplies tls-server-end-point channel
binding, so tokio-postgres negotiates SCRAM-SHA-256-PLUS when the upstream
offers it. The rustls stream returns ChannelBinding::none(), so channel binding
is never available and the client always falls back to plain SCRAM-SHA-256.

Impact is limited: no consumer sets channel_binding=require (confirmed — the
only channel_binding references in-tree are the server-side pgwire SCRAM
decoder, unrelated), so tokio-postgres runs with the default prefer, where the
loss is a silent no-op rather than a failure, and an active MITM can already
strip the -PLUS offer under prefer. Still, in sslmode=require (no cert
verification — the recommended Materialize PG source mode, since prefer is
intentionally disallowed) channel binding was the only MITM defense the openssl
path offered against a network attacker, and this removes it. Not tracked in
SEC-192. Worth restoring tls-server-end-point (rustls exposes the peer cert via
TlsStream::get_ref().1.peer_certificates()) when the client flip lands, or at
least recording the gap.