Propagators API

[hdost]

According to the spec the propagators https://github.com/open-telemetry/opentelemetry-rust/blob/main/opentelemetry-sdk/src/propagation/composite.rs should be in the API instead of the SDK

Context Conversation: https://cloud-native.slack.com/archives/C03GDP0H023/p1679426866872239

[wperron]

As far as I understand it the current structure does respect the spec; the TextMapPropagator is defined in the API, and specific implementations are found in the SDK. Digging around, seems like this conversation already occurred in #266. @jtescher might know more.

[hdost]

If that were the case then these should also be in the SDK.
Java
C#

As well the specific propagators such as Jaeger and B3(a.k.a Zipkin) should be in different extension crates and the W3C ones can (probably should by included in the API).
https://sourcegraph.com/github.com/open-telemetry/opentelemetry-specification/-/blob/specification/context/api-propagators.md#propagators-distribution
Though

[cijothomas]

https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/context/api-propagators.md#propagators-distribution From this spec, the W3C propagators may be distributed as part of API packages.

[TommyCpp]

Distribution of propagators in other language:

Propagator	Language	Location
baggage propagator	Go	API / propagation
baggage propagator	Java	API / baggage
baggage propagator	.NET	API / propagation
trace context propagator	Go	API / propagation
trace context propagator	Java	API / propagation
trace context propagator	.NET	API / propagation
composite propagator	Go	API / propagation
composite propagator	Java	API / propagation
composite propagator	.NET	API / propagation

For composite propagator I think we should move it to API because:

• I see it more of a generic helper instead of an actual implementation so it's consistent with the definition of API
• Most language implement is as part of the API along with the interface. Jave even implemented a composite method in the interface

For baggage propagator and trace context propagator I think we can leave them in the SDK for now. Although it's different from other languages I think it's aligned with our principle to keep the interfaces and implementations separate