Remove Included Propagators section from trace API spec

[MrAlias]

This is a duplicate of the Propagators Distribution of the context specification.

Fixes #1544

[utpilla]

LGTM.

[carlosalberto]

Not quite a duplicate, as the Propagators Distribution is a general note, while this one is about the API being the place where TraceContext lives. That being said, we may need to have better wording for it, in order to avoid confusion.

[MrAlias]

Not quite a duplicate, as the Propagators Distribution is a general note, while this one is about the API being the place where TraceContext lives. That being said, we may need to have better wording for it, in order to avoid confusion.

@carlosalberto I'm not sure I follow. From this section of the specification:

The API layer or an extension package MUST include the following Propagators

My understanding reading that is that the API or an extension package is the place TraceContext lives. Additionally this is restated in the Propagators Distribution section:

The official list of propagators that MUST be maintained by the OpenTelemetry organization and MUST be distributed as OpenTelemetry extension packages [include] W3C TraceContext [which] MAY alternatively be distributed as part of the OpenTelemetry API.

This excerpt from the Propagators Distribution section contains normative requirements and options and doesn't seem to be a note.

[carlosalberto]

@MrAlias You are definitely correct - the original intention of that paragraph in api.md (before the amendment in the Propagators Distribution doc), is that we really suggest SIGs to have the TraceContext (and Baggage) propagators right in the base API packages, even if distributing them as extension packages is allowed.

[MrAlias]

@carlosalberto I'm still not 100% sure what your suggestion for a change here is?

You would definitely be the one to know what the original intention was there and I don't mean to step on toes. I'm just going off what the final result ended up being and what was released. Based on how both section of the specification are written today they appear to me to be duplicates and removing the less comprehensive of the two seems like a good way to remove redundancy and avoid future confusion and internal divergences.

[carlosalberto]

@MrAlias We just need a small note here regarding that we suggest (not even a SHOULD) that SIGs include this TracePropagator in the API package/artifact itself. Will do that myself to not stale this PR any longer. Thanks!