feat(otlp): Re-export tonic crate

[MathieuTricoire]

Fixes #882

Design discussion issue

I chose to re-export the entire tonic crate instead of cherry-picking types to avoid maintenance overhead. The re-export is gated behind the grpc-tonic feature.

Let me know your thoughts if re-exporting the whole tonic crate is too much and how we should tackle this in this situation.

Changes

Re-exports the entire tonic crate from the opentelemetry-otlp crate, to allows downstream crates to use tonic types (such as MetadataMap) compatible with opentelemetry-otlp without needing to manually match the internal tonic version.

Merge requirement checklist

• CONTRIBUTING guidelines followed
• Unit tests added/updated (if applicable)
• Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
• Changes in public API reviewed (if applicable)

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: cijothomas / name: Cijo Thomas (23fd53d, a46b881, e016808, b491c2d)
• ✅ login: MathieuTricoire / name: Mathieu Tricoire (aadc48f, 2809ede, bd0af70, 0809e5b, 2150812, 31f38a7, 156bb7a, 19b5c90, 710b2b2)
• ✅ login: lalitb / name: Lalit Kumar Bhasin (36fbc57, 509e48c)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.3%. Comparing base (409713d) to head (0809e5b).
Report is 1 commits behind head on main.

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #2898   +/-   ##
=====================================
  Coverage   81.3%   81.3%           
=====================================
  Files        126     126           
  Lines      24294   24294           
=====================================
  Hits       19774   19774           
  Misses      4520    4520           

☔ 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.

[lalitb]

@MathieuTricoire Re-exporting the whole tonic crate works, but it exposes all of tonic’s API as part of our public API. If we only need a few types (like MetadataMap), we could selectively re-export just those (e.g., pub use tonic::metadata::MetadataMap;). If more types are needed in the future, we can always add them as needed. Or do you see a reason to expose the whole crate up front?

[MathieuTricoire]

@lalitb Thanks for the answer! That makes sense, and I'm totally good with cherry-picking. I actually thought about that, but I didn't want to overthink it right away if not necessary.

Going cherry-picking route, I see two options:

Flat re-export:

#[cfg(feature = "grpc-tonic")]
pub mod tonic_types {
    #[doc(no_inline)]
    pub use tonic::metadata::MetadataMap;
    #[doc(no_inline)]
    #[cfg(feature = "tls")]
    pub use tonic::transport::{Certificate, ClientTlsConfig, Identity};
}

Grouped by module:

#[cfg(feature = "grpc-tonic")]
pub mod tonic_types {
    pub mod metadata {
        #[doc(no_inline)]
        pub use tonic::metadata::MetadataMap;
    }

    #[cfg(feature = "tls")]
    pub mod transport {
        #[doc(no_inline)]
        pub use tonic::transport::{Certificate, ClientTlsConfig, Identity};
    }
}

I kind of like the module-based one, feels cleaner and easier to extend later to me, but maybe over-engineered? Happy to go with whichever makes more sense for you.

Also wondering what you think about the naming, would tonic_types work? Or maybe tonic_compat, tonic_export, or something else?

Also are you ok with the current re-export scope?

Let me know what direction you'd prefer and I'll adjust the PR 👍

[MathieuTricoire]

I pushed the grouped by module proposal, let me know your thoughts.

[lalitb]

thanks @MathieuTricoire - I agree - the module-based structure feels cleaner and more future-proof, especially if we add more exports later. So let's go with that.

[bantonsson]

👍🏻 on the module based approach

[bantonsson]

I assume that all of these should be reexported and removed?

[MathieuTricoire]

Hi @bantonsson, thanks for the review!
The added types are the ones now re-exported.
I also updated the CI script to check allowed external types with all features enabled, because the previous configuration was correct but wasn't actually enforced (some re-exported types are feature-gated).
I've also cleaned up the old types that are no longer re-exported.

[bantonsson]

Thanks for the explanation @MathieuTricoire. Didn't know how that plugin works.

[bantonsson]

Thanks for the explanation @MathieuTricoire. Didn't know how that plugin works.

[MathieuTricoire]

CI has been fixed after the merge of #2945 and the PR should be ready for merging.

I have checked the Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes requirement, but do you think a CHANGELOG update is needed?

[cijothomas]

Looks good, can you add a changelog entry too?

[MathieuTricoire]

Hi @cijothomas, I've added the changelog entry, let me know if that works for you 👍