feat: make rustls-backed TLS an opt-in feature

[donbeave]

What

The manifest unconditionally enables tonic's tls-ring feature, so every consumer carries a rustls/tokio-rustls dependency — even when connecting over plaintext to a trusted local endpoint, or when their organization mandates the operating system's native TLS stack and forbids bundled rustls trust roots.

This PR makes TLS opt-in via a new tls-ring crate feature that forwards to tonic/tls-ring:

• Without the feature the client is plaintext-only: Certificate/Identity/ClientTlsConfig imports, the client_tls_config channel state, ChannelManager::with_tls_config, and Client::with_tls_and_urls are cfg-gated, and endpoint URLs are always http.
• ClientTlsOption and ChannelConfig::client_tls stay available unconditionally so configuration parsing does not change shape.
• With --features tls-ring everything behaves exactly as before.

Verification

• cargo check/cargo test --no-default-features: green, and cargo tree -i rustls / -i tokio-rustls match no packages
• cargo check/cargo test --features tls-ring: green
• cargo check/cargo test (default features): green
• cargo fmt --check, cargo clippy --no-default-features: clean

Note on compatibility

This changes the implicit default: consumers relying on TLS today need to enable the tls-ring feature explicitly. If you prefer to keep backward compatibility, an alternative is default = ["tls-ring"] — plaintext consumers would then use default-features = false. Happy to switch to that shape if you prefer.

Context: we ship an observability tool (Parallax) with a strict native-TLS-only dependency policy and a plaintext trusted local hop to a managed GreptimeDB; the unconditional rustls edge is currently the only thing keeping us on the HTTP SQL path instead of the row API. A follow-up we'd also be interested in contributing is a native-TLS connector via Endpoint::connect_with_connector_lazy.

🤖 Generated with Claude Code