`azure_messaging_eventhubs` should allow users to use `rustls` instead of `native-tls`

[georgeh0]

Feature Summary

Currently, the azure_messaging_eventhubs requires native-tls (OpenSSL) for TLS connections. This creates significant friction for cross-platform Rust applications and libraries.

Feature Description

Summary:
Currently, the azure_messaging_eventhubs requires native-tls (OpenSSL) for TLS connections. This dependency is introduced by: azure_messaging_eventhubs -> azure_core_amqp -> fe2o3-amqp -> native-tls. fe2o3-amqp is configured as part of the workspace dependency here, and users have no way to remove it, as it's not guarded by a feature. This creates significant friction for cross-platform Rust applications and libraries. Many Rust projects—including ours—use rustls for TLS because it is pure Rust, easier to build, and more portable (especially for static builds, containerized deployments, and platforms where OpenSSL is problematic).

Request:
Please add support for using rustls as a TLS backend, controlled by a Cargo feature flag (e.g., rustls-tls, following the convention of crates like reqwest and hyper). This will allow users to choose their preferred TLS implementation and greatly improve the ease of building and distributing Rust applications that integrate with Azure services.

You can still by default enable the native-tls feature, so existing clients won't break, but allow users turn off defaults and enable rustls instead.

Benefits:

• Better cross-platform compatibility (especially for Windows, Mac, and minimal Linux containers)
• Simplified dependency management and deployment (no external C libraries)
• Aligns with modern Rust ecosystem practices

Thank you for considering this feature—it would be a major improvement for Rust users integrating with Azure event hubs!

Use Case

No response

Alternatives

No response

Additional Context

No response

[heaths]

Alternatively, do we even need to declare features in our own crates? See #2811 (review). I appreciate it's slightly different because there's no dependency on reqwest here, but the fact is that we still depend on resolver v2 or newer and mutually exclusive features aren't permitted (just don't work). So as long as we declare features on only those hard dependencies we have - which doesn't include exactly which TLS implementation is used - anyone using our crates could just as easily take a dependency on - in this case - fe2o3-amqp and add those features they require. Would that work? Not only would that eliminate any dependency on ring, but it also means not complicating the surface area of using our crates and allowing for more customization upstream. No need for 1:1 parity in features in our crate, which gets unwieldy to maintain and use.

Would that work for you?