Support dynamic client certificate resolution (ResolvesClientCert)

[brucearctor]

Support dynamic client certificate resolution (ResolvesClientCert)

What

Add a client_cert_resolver field to TlsOptions that accepts an Arc<dyn ResolvesClientCert> for dynamic, per-handshake client certificate selection. This enables transparent mTLS certificate rotation without requiring a process restart — useful for short-lived certificates managed by Vault agents, cert-manager sidecars, or HSM-backed signers.

Closes #1338

Why

The existing client_tls_options requires static (cert, key) bytes at connection time. Users with rotating certificates (e.g., Vault-issued certs with 24h TTLs) must restart the entire Temporal client to pick up new material. The Go SDK solves this with tls.Config.GetClientCertificate; this PR brings equivalent functionality to the Rust SDK.

How

Since tonic 0.14.6 does not expose rustls::ClientConfig::with_client_cert_resolver(), the implementation bypasses tonic's TLS layer when a resolver is present:

1. build_custom_rustls_config() — manually constructs a rustls::ClientConfig with the user's ResolvesClientCert, replicating tonic's security defaults (protocol versions, ALPN, native/custom CA roots)
2. DynamicTlsConnector — a tower::Service<Uri> that wraps TCP with TLS using tokio_rustls::TlsConnector, including connect timeouts and tracing
3. Endpoint::connect_with_connector() — used instead of connect() to wire the custom connector into tonic's channel

The resolver fires on each new TLS handshake (reconnections), not per-RPC over an existing HTTP/2 connection.

Key design decisions

• Mutually exclusive with static certs — setting both client_tls_options and client_cert_resolver returns InvalidConfig
• Re-exports — ResolvesClientCert, CertifiedKey, and SignatureScheme are re-exported at the crate root so users don't need to depend on tokio-rustls directly
• DNS load balancing — returns a clear error (not yet supported with dynamic certs due to balance_channel API constraints)
• Proxy — returns a clear error (not yet supported; would require composing connectors)
• C bridge — hardcodes client_cert_resolver: None (dynamic resolution from C callers needs a callback design in a follow-up)

Changes

File	Change
crates/client/src/options_structs.rs	Add client_cert_resolver field, update Debug impl
crates/client/src/lib.rs	TlsConfigResult enum, add_tls_to_channel branching, build_custom_rustls_config, DynamicTlsConnector, proxy/DNS validation, tracing
crates/client/src/dns.rs	Handle TlsConfigResult, reject resolver + DNS LB
crates/client/src/envconfig.rs	Add client_cert_resolver: None
crates/client/Cargo.toml	Add rustls-native-certs dep
crates/sdk-core-c-bridge/src/client.rs	Add client_cert_resolver: None
crates/sdk-core/tests/common/mod.rs	Update test struct literals
CHANGELOG.md	Add entry under [Unreleased] > Added

Tests (15 new, 134 total pass)

• Custom connector returned when resolver is set (explicit domain + inferred domain)
• Mutual exclusion: static + dynamic certs → error
• Resolver + custom ServerCertVerifier combination
• Resolver + custom CA certificate
• build_custom_rustls_config with/without resolver/verifier
• Debug output correctness for TlsOptions with resolver
• DynamicTlsConnector is Clone + Debug
• Default TlsOptions has no resolver
• No-TLS passthrough returns Standard
• IP host fallback for domain extraction
• Re-exports compile (CertifiedKey, SignatureScheme)

Future work

• SDK-owned convenience trait (decouple users from rustls types) — Provide SDK-owned trait for dynamic client certificates (decouple from rustls) #1341
• Connection max-lifetime for proactive cert rotation — Add connection max-lifetime for proactive mTLS certificate rotation #1342
• DNS load balancing + dynamic certs — Support dynamic client cert resolver with DNS load balancing #1343
• C bridge callback support — Expose dynamic client cert resolver via C bridge for language SDKs #1344
• FileWatchingCertResolver batteries-included implementation — Provide batteries-included FileWatchingCertResolver for common mTLS rotation #1345

[chris-olszewski]

Will be giving this a review very soon, thanks for your patience.

[brucearctor]

i'm in no rush

[chris-olszewski]

Overall I think this design makes sense to me. The largest thing for me is making sure we feature gate it.

[brucearctor]

@chris-olszewski - i think addressed?

[chris-olszewski]

Looks good to me. Only a few questions on some of the new tests and a suggestion that we mark this variant as experimental. Thanks for your patience on the review process.

[brucearctor]

@chris-olszewski — rebased onto main and addressed your outstanding comments.

Summary:

Removed the re_exports_are_accessible test — you were right that use super::* imports parent imports, not just public exports, so it wasn't actually testing the re-export surface. The re-exports are exercised implicitly by the other dynamic-tls tests.
The dynamic_tls_connector_is_clone_and_debug removal and "Experimental API" doc comment were already in place from earlier.

Merge conflict:

Rebased onto current main. The only conflict was integrating #1422's connect_timeout — it slots in between Endpoint::from_shared() and add_tls_to_channel() in the dynamic-tls path.

IPv6 fixes (new): While doing a deeper review of the connector code, caught two IPv6 bugs:

• DynamicTlsConnector::call used format!("{host}:{port}") for TcpStream::connect, which produces ambiguous addresses for IPv6 (e.g. ::1:443). Switched to the (host, port) tuple form of ToSocketAddrs.
• SNI domain extraction from uri.host() returns brackets for IPv6 literals ([::1]), which ServerName::try_from rejects. Now strips brackets before conversion.

All 166 tests pass with --features dynamic-tls, 154 pass on default features.