cosmos: add configurable TLS backend, enforced on reqwest

[ananth7592]

Problem

The driver does not expose direct access to its HTTP transport (and won't, in a supported fashion). As a result, customers have no supported way to assert a specific TLS backend on the officially-supported reqwest transport.

Change

Introduces a supported, forward-looking mechanism to select and enforce the TLS backend.

• TlsBackend enum — #[non_exhaustive], one variant TlsBackend::Rustls (the #[default]). Added to azure_data_cosmos_driver and re-exported from azure_data_cosmos.
• ConnectionPoolOptions::tls_backend — new option with ConnectionPoolOptionsBuilder::with_tls_backend and a tls_backend() getter, defaulting to Rustls. Builder-only (intentionally not environment-configurable).
• Enforced on reqwest — DefaultHttpClientFactory::build selects the backend and calls reqwest::ClientBuilder::tls_backend_rustls(). The call is cfg-gated on the rustls feature because that reqwest method only exists when reqwest's rustls backend is compiled in; under a different TLS feature the reqwest default applies.

Because there is a single variant and it is the default, no customer configuration is required today. The value is forward-looking: it lets us add new backends in a supported way, and (once #4616 lands) hand the selected backend to a user-provided HttpClientFactory.

Files

• options/policies.rs — new TlsBackend enum.
• options/mod.rs (driver) and options/mod.rs (SDK) — export / re-export TlsBackend.
• options/connection_pool.rs — tls_backend field, builder field, with_tls_backend, getter, default wiring; extended option tests.
• driver/transport/http_client_factory.rs — enforce the backend on the reqwest builder; factory build test.
• CHANGELOG.md (driver 0.6.0, SDK 0.37.0) — Features Added entries.

Testing & coverage

Unit (added):

• connection_pool_options_builder_defaults — default tls_backend() is Rustls.
• connection_pool_options_builder_custom_values — with_tls_backend() round-trips through the builder.
• default_factory_builds_client_with_default_tls_backend (reqwest-gated) — builds a real reqwest::Client with the default backend, exercising tls_backend_rustls() and asserting build() succeeds.

Suites / static checks (green): 1878 driver lib unit tests; cargo clippy --all-features --all-targets; cargo doc; cargo fmt --check; cSpell. Compile verified for both the rustls and the not(rustls) (reqwest + native_tls) feature paths — the main risk surface for the cfg-gated call.

Integration testing: No dedicated integration test is added, by design. Rustls is the only variant and the default, and the default feature set already used reqwest-over-rustls — so behavior is unchanged and the existing emulator/recorded integration suites already exercise the rustls transport path end-to-end. A bespoke test could not assert more, because reqwest exposes no API to introspect which TLS backend negotiated a connection; the added factory test already proves the client builds and runs with the enforced backend.

Fixes #4641.

[Copilot]

Pull request overview

This PR adds a supported, forward-looking mechanism for asserting the TLS backend used by the Cosmos DB driver's officially-supported reqwest transport. Since the driver intentionally does not expose direct transport access, customers previously had no supported way to pin a TLS backend. The change introduces a TlsBackend enum (single Rustls variant, which is the default), surfaces it as a builder-only ConnectionPoolOptions::tls_backend option, and enforces it on the reqwest::ClientBuilder via tls_backend_rustls(). Because there's a single variant that is also the default, no customer configuration is required today; the value is forward-looking (supports future backends and, per #4616, handing the backend to a user-provided HttpClientFactory).

Changes:

• New #[non_exhaustive] TlsBackend enum in the driver, re-exported through azure_data_cosmos.
• New tls_backend field/getter/with_tls_backend builder on ConnectionPoolOptions, defaulting to Rustls, builder-only (not env-configurable).
• Enforcement on the reqwest builder via tls_backend_rustls(), cfg-gated on the rustls feature, with added unit tests and CHANGELOG entries.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
sdk/cosmos/azure_data_cosmos_driver/src/options/policies.rs	Adds the TlsBackend enum with Rustls as the #[default] variant.
sdk/cosmos/azure_data_cosmos_driver/src/options/mod.rs	Re-exports TlsBackend from policies.
sdk/cosmos/azure_data_cosmos/src/options/mod.rs	Re-exports TlsBackend from the driver into the SDK surface.
sdk/cosmos/azure_data_cosmos_driver/src/options/connection_pool.rs	Adds the tls_backend field, getter, builder setter, default wiring, and tests.
sdk/cosmos/azure_data_cosmos_driver/src/driver/transport/http_client_factory.rs	Enforces the selected backend on the reqwest builder (cfg-gated) and adds a build test.
sdk/cosmos/azure_data_cosmos_driver/CHANGELOG.md	Documents the new feature under the unreleased 0.6.0 Features Added section.
sdk/cosmos/azure_data_cosmos/CHANGELOG.md	Documents the re-exported feature under the unreleased 0.37.0 Features Added section.

I verified the key risk areas:

• reqwest::ClientBuilder::tls_backend_rustls() genuinely exists in reqwest (locked at 0.13.3), gated on reqwest's internal __rustls feature. The driver's rustls feature enables reqwest/rustls, so the #[cfg(feature = "rustls")] gate on the call correctly matches method availability, and the not(rustls) path compiles by leaving the builder unchanged.
• The CosmosOptions derive macro (in env_only mode) tolerates the new tls_backend field having no #[option] attribute — it emits tls_backend: None in the generated from_env_vars, consistent with the builder-only design.
• ConnectionPoolOptions is only ever constructed via build(), so the added field doesn't break any struct-literal construction.
• CHANGELOG entries are placed under the existing Features Added headers in the unreleased sections, and the re-export is mirrored from the driver into azure_data_cosmos as required.

I did not find any objective issues to comment on.

[FabianMeiswinkel]

LGTM