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: MathieuTricoire / name: Mathieu Tricoire (aadc48f, 2150812, 710b2b2, 31f38a7, bd0af70)
• ✅ login: cijothomas / name: Cijo Thomas (23fd53d, e016808, b491c2d, a46b881)
• ✅ login: lalitb / name: Lalit Kumar Bhasin (509e48c, 36fbc57)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.3%. Comparing base (b5d31f1) to head (36fbc57).

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #2898   +/-   ##
=====================================
  Coverage   81.3%   81.3%           
=====================================
  Files        126     126           
  Lines      24254   24254           
=====================================
+ Hits       19736   19737    +1     
+ Misses      4518    4517    -1     

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