Rust SDK hard-codes native-tls (OpenSSL); offer a rustls TLS backend so musl/static builds work

Empieza inspeccionando rust/Cargo.toml y ejecutando el cargo build indicado para x86_64-unknown-linux-musl. Rastrea las características TLS de reqwest y tokio-tungstenite y, a continuación, confirma que el backend predeterminado elegido o activado mediante features se compila sin requerir OpenSSL del sistema, manteniendo la funcionalidad solicitada del cliente.

Summary

The Rust crate (rust/Cargo.toml) hard-codes the OpenSSL-backed native-tls stack for its 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. These deps were introduced with the HTTP request callback support in #1689.

Impact

• musl / fully-static targets fail to build. Cross-compiling to *-unknown-linux-musl fails in the openssl-sys build script with Could not find openssl via pkg-config / Could not find directory of OpenSSL installation, because there is no OpenSSL sysroot for the musl target. Consumers that ship static binaries (Alpine, distroless, hardened CI) cannot build the Rust SDK without vendoring OpenSSL.
• glibc binaries gain a dynamic libssl runtime dependency. Even where the build succeeds, the resulting binary now dynamically links libssl.so.3 / libcrypto.so.3, narrowing portability for consumers that previously shipped self-contained rustls binaries.

Request

Make the TLS backend rustls-based, or feature-gate it so consumers can choose. Two shapes:

1. Default to rustls — reqwest rustls-tls (or rustls-tls-native-roots) and tokio-tungstenite rustls-tls-native-roots. The ring / aws-lc-rs backends cross-compile to musl with no system OpenSSL, keeping the SDK OpenSSL-free out of the box.
2. Expose cargo features (e.g. native-tls vs rustls-tls) so downstreams pick a backend, while keeping native-tls available for those who want it.

Option 1 keeps the SDK cross-compilable by default; option 2 preserves choice. Happy to open a PR once you confirm the preferred shape.

Repro

With musl-tools installed:

cargo build -p <rust-sdk-crate> --target x86_64-unknown-linux-musl

fails in the openssl-sys build script.