Stop listing ring in Cargo.lock when ring feature is not enabled

[ismailhkose]

Problem

Downstream consumers of rustls-webpki 0.103.x that do not enable the ring feature still see ring v0.17.14 recorded in their Cargo.lock. The crate is never actually compiled (verified via cargo tree, cargo metadata, and inspection of target/), but the phantom entry shows up in dependency audits and confuses users on the rustls + alternative-provider path (e.g. consumers using rustls-symcrypt, rustls-graviola, or another custom provider).

Root cause: the alloc feature uses the weak optional-dep activator ring?/alloc. Cargo's resolver records resolved versions for any optional dep referenced via dep?/..., even when the activation condition is never met by any consumer in the workspace.

Fix

Drop ring?/alloc from the alloc feature. Move the ring/alloc activation onto the ring feature itself, and have ring imply alloc.

This matches the existing source layout: the ring-backed RSA verification algorithms in src/ring_algs.rs are gated on cfg(all(feature = \"ring\", feature = \"alloc\")) and reference ring APIs that themselves require ring/alloc, so any practical user of the ring feature already had to enable alloc for a useful RSA-capable build.

Verification

• cargo check across {default, --no-default-features, alloc, ring, ring,alloc, ring,std, aws-lc-rs, --all-features} — all pass
• cargo test --features ring,alloc,std --no-default-features — all suites green
• cargo test --features aws-lc-rs,alloc,std --no-default-features — all suites green
• Confirmed minimal one-line removal (ring?/alloc deletion alone) is insufficient: it breaks --features ring,alloc because the RSA algorithm static items reference ring APIs gated on ring/alloc. Hence the two-line variant in this PR.
• In a downstream workspace using rustls + rustls-symcrypt (no ring feature enabled by anyone), applying this patch via [patch.crates-io] causes ring to disappear from Cargo.lock and rustls-webpki's resolved deps to shrink to rustls-pki-types and untrusted.

Compatibility

Minor feature-graph expansion: enabling ring now transitively activates alloc and ring/alloc, exposing RSA APIs in addition to ECDSA. No public API is removed.

The only edge case affected is a no_std-with-ring-but-explicitly-no-alloc build, which previously got an ECDSA-only surface and now picks up alloc implicitly. Worth a CHANGELOG note. In practice this configuration is uncommon since the ECDSA-only ring build offers a small benefit and most ring-feature users enable alloc anyway.

Scope

main already addresses this differently for 0.104 (commit drops the ring and aws-lc-rs integrations from the main crate entirely, splitting them into separate rustls-ring / rustls-aws-lc-rs crates). This PR only targets rel-0.103 to clean up the lockfile noise on the currently released line during the time before 0.104 stable.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.42%. Comparing base (2879b2c) to head (e4a3e1c).

Additional details and impacted files

@@            Coverage Diff             @@
##           rel-0.103     #487   +/-   ##
==========================================
  Coverage      97.42%   97.42%           
==========================================
  Files             19       19           
  Lines           3845     3845           
==========================================
  Hits            3746     3746           
  Misses            99       99           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[djc]

I don't like the trade-off of working around a Cargo resolver issue by forcing alloc on everyone who wants to use ring. Suggest you find a different way to audit your dependencies, or maybe try to fix the Cargo issue.

rust-lang/cargo#10801