use-rustls-ring transitively enables rustls/default (aws-lc-rs), breaking ring-only builds

[EddieHouston]

In 0.25.0 the rustls-ring feature is defined as:

rustls-ring = [
    "webpki-roots",
    "dep:rustls",
    "rustls/ring",
    "rustls/logging",
    "rustls/std",
    "rustls/tls12",
]

The "rustls/ring" entries (without ?) also activate the crate's explicit rustls feature:

rustls = [
    "webpki-roots",
    "dep:rustls",
    "rustls/default",
]

which enables rustls/default, i.e. the aws-lc-rs provider. So a downstream crate asking for use-rustls-ring (expecting ring only) ends up with both ring and aws-lc-rs enabled on rustls. cargo tree -e features shows the chain:

electrum-client feature "rustls"
  └── electrum-client feature "rustls-ring"
      └── electrum-client feature "use-rustls-ring"

Consequences downstream: rustls can no longer auto-select a process-level CryptoProvider, so any other crate in the same binary that relies on the process default panics on first TLS use with:

Could not automatically determine the process-level CryptoProvider from Rustls crate features.

(electrum-client itself is unaffected since it selects its provider explicitly.) We hit this in a project after bumping electrum-client 0.21 -> 0.25: the shared rustls went from ring only to ring + aws-lc-rs + default, and an unrelated tokio-tungstenite connection in the same binary started panicking.

Suggested fix

Use the ? syntax so rustls-ring does not activate the rustls feature:

rustls-ring = [
    "webpki-roots",
    "dep:rustls",
    "rustls?/ring",
    "rustls?/logging",
    "rustls?/std",
    "rustls?/tls12",
]

(0.21 did not have this problem; the regression came with the feature reshuffle in later releases.)