Support pluggable rustls crypto providers (ring, aws-lc-rs, OpenSSL) …

[pritishnahar95]

Change Summary

Support pluggable rustls crypto providers (ring, aws-lc-rs, OpenSSL) via
compile-time feature flags. TLS support previously hardcoded ring as the
rustls crypto backend. This PR introduces three mutually exclusive feature
flags (crypto-ring, crypto-aws-lc, crypto-openssl) so users can select
their preferred CryptoProvider at build time, enabling compliance with
environments that require OpenSSL or FIPS-validated cryptography.

What issue does this PR close?

• closes Support pluggable rustls crypto providers (ring, aws-lc-rs, OpenSSL) via feature flags #2251

How are these changes tested?

• cargo check passes with default features (crypto-ring).
• cargo check --no-default-features --features jemalloc,crypto-openssl,experimental-tls passes.
• All existing TLS tests (tls_utils, mtls_tests, tls_stream, tls_reload,
  otlp_exporter_tls, otlp_exporter_proxy_tls) now use the centralized
  install_crypto_provider() helper and will exercise whichever backend is
  selected by feature flags.
• compile_error! guards prevent enabling multiple crypto features simultaneously.

Are there any user-facing changes?

Yes:

• New feature flags on the root crate and otap-df-otap:
  • crypto-ring (default) — uses ring, backward-compatible.
  • crypto-aws-lc — uses aws-lc-rs for AWS environments.
  • crypto-openssl — uses rustls-openssl for regulated/FIPS environments.
• Default behavior is unchanged — crypto-ring is included in the default
  feature set, so existing builds are unaffected.
• To build with OpenSSL: cargo build --no-default-features --features jemalloc,crypto-openssl
• Transitive ring dependencies from opentelemetry-otlp (via reqwest 0.12)
  and weaver (via ureq) remain and are tracked for resolution as upstream
  crates release updates. Weaver is dev/test tooling only, not a production
  pipeline component.

[codecov]

Codecov Report

❌ Patch coverage is 92.85714% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 87.55%. Comparing base (e46f91a) to head (4be43b1).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2269      +/-   ##
==========================================
- Coverage   87.56%   87.55%   -0.01%     
==========================================
  Files         570      571       +1     
  Lines      193480   193505      +25     
==========================================
+ Hits       169414   169423       +9     
- Misses      23540    23556      +16     
  Partials      526      526              

Components	Coverage Δ
otap-dataflow	89.58% <92.85%> (-0.01%)	⬇️
query_abstraction	80.61% <ø> (ø)
query_engine	90.63% <ø> (ø)
syslog_cef_receivers	∅ <ø> (∅)
otel-arrow-go	52.44% <ø> (ø)
quiver	91.91% <ø> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[drewrelmas]

Looks good to me, we can take my questions on removal of experimental-tls feature flag up in later PR.

Would like to wait for @lalitb's approval as well before merging.

[lalitb]

LGTM! Clean abstraction for pluggable crypto providers - nice work @pritishnahar95.

[lquerel]

@pritishnahar95 @jmacd

Transitive ring dependencies from opentelemetry-otlp (via reqwest 0.12)
and weaver (via ureq) remain and are tracked for resolution as upstream
crates release updates. Weaver is dev/test tooling only, not a production
pipeline component.

I'm wondering whether we actually have a real problem here. In the medium term, I expected that we would no longer have opentelemetry-otlp as a dependency once the refactoring of the internal telemetry pipeline is completed. OTLP and OTAP export would be handled by our exporters, which would rely on the encryption layer defined by these new feature flags.

Regarding Weaver, we could imagine introducing a feature that enables dev-only capabilities (disabled by default). If we do that, it seems to me that nothing would remain that is not configured through the feature flags introduced in this PR.

[lquerel]

LGTM

[pritishnahar95]

@pritishnahar95 @jmacd

Transitive ring dependencies from opentelemetry-otlp (via reqwest 0.12)
and weaver (via ureq) remain and are tracked for resolution as upstream
crates release updates. Weaver is dev/test tooling only, not a production
pipeline component.

I'm wondering whether we actually have a real problem here. In the medium term, I expected that we would no longer have opentelemetry-otlp as a dependency once the refactoring of the internal telemetry pipeline is completed. OTLP and OTAP export would be handled by our exporters, which would rely on the encryption layer defined by these new feature flags.

Regarding Weaver, we could imagine introducing a feature that enables dev-only capabilities (disabled by default). If we do that, it seems to me that nothing would remain that is not configured through the feature flags introduced in this PR.

That's a good point @lquerel! Let's tackle the weaver feature-gating in a separate issue/PR since it seems to touch the fake_data_generator module, its linkme registrations, and test/validation configs — better as a focused follow-up.