tls-util: migrate mz-tls-util from openssl to rustls

[jasonhernandez]

Summary

Migrate mz-tls-util — the central client-side TLS abstraction — from openssl/postgres-openssl to rustls/tokio-postgres-rustls with aws-lc-rs as the crypto backend.

• make_tls() now returns MakeRustlsConnect using rustls::ClientConfig configured via mz_ore::crypto::fips_crypto_provider(), with appropriate cert verification for each SSL mode (VerifyFull, VerifyCa via custom CaOnlyVerifier, NoVerify for Disable/Prefer/Require-no-CA)
• TlsError::OpenSsl replaced with TlsError::Rustls
• pkcs12der_from_pem() removed from mz-tls-util; inlined into ccsr and storage-types which still need PKCS#12 for their downstream TLS libraries (reqwest native-tls, mysql_async)
• postgres-util: removed PostgresSsl(openssl::error::ErrorStack) variant, removed openssl + postgres-openssl deps
• mz-debug: switched to MakeRustlsConnect, refactored connection setup

Dependencies

This PR is based on jason/sec-219-tls-test-infra which includes prerequisite PRs:

• SEC-215: Unblock rustls and add FIPS feature flag
• SEC-176: Remove rustls ban from deny.toml
• SEC-219: Server-side TLS migration

Works toward SEC-192.

Test plan

• cargo check -p mz-tls-util — compiles cleanly
• cargo check -p mz-ccsr — compiles cleanly
• cargo check -p mz-testdrive — compiles cleanly
• cargo check -p mz-storage-types — compiles cleanly
• cargo check -p mz-postgres-util --features tunnel — compiles cleanly
• cargo clippy -p mz-tls-util — no warnings
• cargo fmt — clean
• CI integration tests (testdrive, SLT) validate TLS connections work end-to-end

Checklist

• Lint clean
• Release notes updated (N/A — internal infrastructure change)

---

🤖 Generated with Claude Code

[github-actions]

Thanks for opening this PR! Here are a few tips to help make the review process smooth for everyone.

PR title guidelines

• Use imperative mood: "Fix X" not "Fixed X" or "Fixes X"
• Be specific: "Fix panic in catalog sync when controller restarts" not "Fix bug" or "Update catalog code"
• Prefix with area if helpful: compute: , storage: , adapter: , sql:

Pre-merge checklist

• The PR title is descriptive and will make sense in the git log.
• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).