prefer rustls for tls runtime and remove compilation error

[nikita-seedlabs]

Since we have a default feature on the rust crate, unless we pass in explicitly --no-default-features when compiling, we end up with both tls runtimes. We don't need this check, since the next one would prefer rustls anyways, and this gets rid of the need to add the no-default-features flag

[Copilot]

Pull request overview

Updates the Rust TLS runtime initialization to prefer rustls when multiple TLS backends are enabled, and improves API documentation around initialization behavior.

Changes:

• Removes the compile-time mutual-exclusion error for tls-rustls + tls-native-tls.
• Makes the tls-native-tls branch a no-op only when tls-rustls is not enabled (so rustls effectively takes precedence).
• Documents that ensure_tls_runtime() can panic when rustls provider installation fails.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The docs here describe behavior for tls-native-tls vs tls-rustls, but the implementation now also supports both features simultaneously (with rustls taking precedence). Please document that precedence explicitly so downstream users aren’t surprised when tls-native-tls is enabled but becomes a no-op due to tls-rustls also being enabled.

[Copilot]

Now that the mutual-exclusion compile_error! was removed, enabling both tls-native-tls and tls-rustls becomes valid and tls-rustls effectively wins. The current compile-time error text can be read as requiring exactly one TLS feature; consider clarifying it (e.g., “at least one TLS feature must be enabled; if both are enabled, rustls is used”).

Suggested change

	compile_error!("one TLS feature must be enabled: `tls-native-tls` (default) or `tls-rustls`");
	compile_error!(
	"at least one TLS feature must be enabled: `tls-native-tls` (default) or `tls-rustls`; \
	if both are enabled, `tls-rustls` is used"
	);