rust: default to rustls TLS backend, add native-tls opt-in

[colbylwilliams]

Summary

Fixes #1805.

The Rust crate hard-coded the OpenSSL-backed native-tls stack for its request-handler HTTP and WebSocket clients, with no way to opt into rustls:

reqwest = { version = "0.12", default-features = false, features = ["stream", "http2", "default-tls"] }
tokio-tungstenite = { version = "0.24", default-features = false, features = ["connect", "native-tls"] }

default-tls (reqwest) and native-tls (tokio-tungstenite) both pull in openssl-sys, which links the system OpenSSL on Linux. This breaks *-unknown-linux-musl / fully-static builds (no OpenSSL sysroot) and adds a dynamic libssl.so.3 runtime dependency on glibc.

Change

This implements both shapes the issue proposed: default to rustls and expose a native-tls cargo feature so consumers keep the choice.

• rustls-tls (new, default): reqwest rustls-tls-native-roots + tokio-tungstenite rustls-tls-native-roots — rustls with the ring provider and the OS trust store. OpenSSL-free, so musl/static targets cross-compile without a system OpenSSL sysroot.
• native-tls (new, opt-in): keeps the platform-native stack (OpenSSL on Linux, Secure Transport on macOS, SChannel on Windows) for consumers who want it.
• Base reqwest/tokio-tungstenite deps drop their hard-coded TLS features; TLS is now selected via the cargo features above.

The transport code (copilot_request_handler.rs) is TLS-backend-agnostic (reqwest::Client::builder() + connect_async), so no source changes were required. For wss://, tokio-tungstenite resolves the rustls crypto provider via Cargo feature unification on the shared rustls crate (reqwest pins ring).

Note: default-features = false now drops the default rustls-tls backend along with bundled-cli; re-add rustls-tls or native-tls. This is documented in the README.

Validation

• cargo build (default) is OpenSSL-free: openssl-sys no longer appears in the normal dependency graph; ring is the sole rustls crypto provider.
• cargo check --no-default-features --features rustls-tls and --features native-tls both compile.
• Verified at runtime that the default rustls wss:// path resolves the ring crypto provider (reaches the TLS handshake instead of panicking with "no process-level CryptoProvider available").
• cargo +nightly fmt --check, cargo clippy --all-features --all-targets -- -D warnings: clean.
• cargo test --all-features: green (177 lib + 365 e2e + integration + 23 doctests).
• Request-handler e2e tests pass under the default rustls-only build (--features test-support).

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

[Copilot]

Pull request overview

This PR updates the Rust SDK crate’s dependency feature wiring so the request-handler transport (reqwest + tokio-tungstenite) defaults to a rustls-based TLS stack (to avoid OpenSSL on Linux/musl/static builds) while still providing an opt-in native-tls feature for consumers who want the platform TLS backend.

Changes:

• Make rustls-tls a new default crate feature and add an opt-in native-tls feature to select the TLS backend.
• Remove hard-coded TLS feature selection from the base reqwest and tokio-tungstenite dependency declarations.
• Document the new feature behavior and default-features = false implications in the Rust README.

Show a summary per file

File	Description
rust/README.md	Documents new rustls-tls (default) and native-tls (opt-in) features and shows updated dependency examples.
rust/Cargo.toml	Adds TLS-selection crate features and removes hard-coded TLS features from transport dependencies.
rust/Cargo.lock	Lockfile updates reflecting the new (feature-gated) dependency graph.

Review details

• Files reviewed: 2/3 changed files
• Comments generated: 1
• Review effort level: Low