Extract OtelData to more stable crate

[mladedav]

Feature Request

Motivation

Currently, if I depend on two projects that differ in the tracing-opentelemetry version used, they do not interoperate well. This is because when a span is created, one library inserts OtelData to the span so that we can use OpenTelemetry but the other cannot find it later.

We have one library for setting up tracing including subscribers and OpenTelemetry machinery and another one which helps us create clients which should also add trace context with HTTP headers to all requests. However, if it uses a different tracing-opentelemetry version, it looks for OtelData but does not find it because the struct is different due to version mismatch.

Proposal

Some data structures not expected to be (breakingly) changed could be extracted to a different crate that would be more stable and all future versions of this crate could depend on it.

This adds a maintenance overhead of multiple crates.

I am unaware of any technical or scoping issues (e.g. pub(crate)).

Alternatives

Usage of multiple versions of the same crate can be checked through tools like cargo-deny. That needs to be configured for every project though. Also, there may be transitive dependencies of the same crate which we would not care about.

[jtescher]

Unfortunately Cargo deny is probably the best bet while the underlying opentelemetry-api and opentelemetry-sdk crates are approaching 1.0. Once there, the rest of the ecosystem can develop structures which will not break, but until that point it is difficult to guarantee.