Clarify how Trace Flags and Tracestate are handled by Trace SDKs

[jmacd]

Part of #1826. Part of #1413.

Changes

The W3C Trace Context Level 2 specification adds a new Random flag intended for use with Probability sampling. The Sampling SIG has produced an OTEP describing how it will be used and how probability sampling can be encoded in the tracestate field. See https://github.com/open-telemetry/oteps/blob/main/text/trace/0235-sampling-threshold-in-trace-state.md

Prototype semantic conventions: https://github.com/open-telemetry/semantic-conventions/pull/793 Prototype collector tail sampler: https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/24811 Prototype sampler logic: https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/29720

Not adding a new spec-compliance matrix for this, we already have "Conforms to the W3C TraceContext spec" however this clarifies what that means. Some SDKs are out of compliance with this specification, but (IMO) not intentionally, so we should not create a new row of the matrix.

• [x] Related issues #1826, #3602
• [x] Related OTEP 235
• [x] Links to the prototypes (when adding or changing features)
• [x] CHANGELOG.md file updated for non-trivial changes
• [x] spec-compliance-matrix.md updated if necessary

[jmacd]

As an example of what this is hoping to clarify, see https://github.com/open-telemetry/opentelemetry-go/issues/5030

[github-actions[bot]]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[jmacd]

@kalyanaj I've updated this PR to reflect the reality of the W3C trace context specification regarding unknown flags. The PR itself is much less important, as a result, but still worth applying.

[github-actions[bot]]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[jmacd]

I may not re-open this; it serves very little purpose in its current form. It shows we need work on #1929.