Enable WITH_OTLP_GRPC_SSL_MTLS_PREVIEW by default

[marcalff]

Fixes # (issue)

Changes

Please provide a brief description of the changes here.

• Enable WITH_OTLP_GRPC_SSL_MTLS_PREVIEW by default in CMake.
• Always build with ENABLE_OTLP_GRPC_SSL_MTLS_PREVIEW in bazel.
• Document deprecations in file DEPRECATED.md.

For significant contributions please make sure you have completed the following items:

• CHANGELOG.md updated for non-trivial changes
• Unit tests have been added
• Changes in public API reviewed

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.18%. Comparing base (f300645) to head (0d146d8).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3970      +/-   ##
==========================================
+ Coverage   90.17%   90.18%   +0.02%     
==========================================
  Files         230      230              
  Lines        7298     7298              
==========================================
+ Hits         6580     6581       +1     
+ Misses        718      717       -1     

see 1 file with indirect coverage changes

🚀 New features to boost your workflow:

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

[dbarker]

Looks good. Thanks!

[lalitb]

One high-level concern: if the goal here is to deprecate WITH_OTLP_GRPC_SSL_MTLS_PREVIEW and move toward always-on support, I think we should make sure Bazel is aligned with that end state as well.

Right now this change moves CMake in that direction, but Bazel still seems not to expose the mTLS-specific API surface. That leaves the feature behavior/build surface inconsistent across build systems during the deprecation period.

If the intended end state is unconditional support, I think it would be good either to align Bazel in the same PR or explicitly call out that this PR is only the CMake side of that transition.

[marcalff]

One high-level concern: if the goal here is to deprecate WITH_OTLP_GRPC_SSL_MTLS_PREVIEW and move toward always-on support, I think we should make sure Bazel is aligned with that end state as well.

Right now this change moves CMake in that direction, but Bazel still seems not to expose the mTLS-specific API surface. That leaves the feature behavior/build surface inconsistent across build systems during the deprecation period.

If the intended end state is unconditional support, I think it would be good either to align Bazel in the same PR or explicitly call out that this PR is only the CMake side of that transition.

I agree, not too happy with the CMake / Bazel lack of symmetry either.

I revised the bazel build to always define ENABLE_OTLP_GRPC_SSL_MTLS_PREVIEW, so that both build enable the feature by default, which is the long term desired state.

Note that there is no opt-out flag for bazel, because no flag was ever exposed, unlike CMake.

PTAL.

If this is satisfactory, I will revise ENABLE_OTLP_RETRY_PREVIEW for bazel as well (in a different PR).

[lalitb]

LGTM. Thanks for handling bazel too in this PR.