crypto: switch HTTP clients from native-tls to rustls

[jasonhernandez]

Summary

• Switch reqwest from native-tls to rustls-tls-webpki-roots-no-provider across ~30 crates
• Switch kube from openssl-tls to rustls-tls + aws-lc-rs
• Switch mysql_async from native-tls to rustls (MaterializeInc fork)
• Switch tiberius from native-tls to rustls (MaterializeInc fork)
• Replace hyper-tls with hyper-rustls in the OpenTelemetry connector (mz-ore tracing)
• Switch launchdarkly-server-sdk from native-tls/crypto-openssl to hyper-rustls-webpki-roots/crypto-aws-lc-rs
• Switch sentry from transport to reqwest feature
• Switch segment to default-features = false
• Update fork overrides for mysql_async, tiberius, duckdb, iceberg
• Add aws-lc-rs CryptoProvider init to binary entry points (clusterd, sqllogictest, testdrive, persist-cli, orchestratord)
• Migrate ccsr TLS cert handling from native-tls/openssl to rustls
• Remove native-tls, tokio-native-tls, hyper-tls from mz-ore tracing feature

Part 3 of 7 in the crypto migration. Depends on PR1 (#35940).

Test plan

• `cargo check --workspace` passes
• No crate depends on native-tls after this PR (ccsr native-tls removed, balancerd LD SDK switched)

🤖 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).