Propagate W3C trace context for unsampled traces in event metadata

[w1am]

Previously, the Java client only wrote tracing metadata ($traceId/$spanId) to appended events when the current trace was sampled. With head-based sampling in production, most events carried no trace context at all. Consumers reading them later couldn't link their spans back to the operation that produced the event, and events written this way can't be fixed retroactively.

Events now carry the standard W3C Trace Context in their metadata. The client writes $traceParent in the W3C format 00-{traceId}-{spanId}-{flags} whenever a trace is active, sampled or not, so consumers can always link back to the producer and see its real sampling decision. When the trace carries vendor state, such as a Datadog sampling decision, the client also writes $traceState.

On read, the client prefers $traceParent and honors its actual flags. Events written by older clients only have $traceId/$spanId, and the client falls back to those, so existing data keeps working.

For a sampled trace, the client keeps writing the legacy fields so consumers on older client versions keep working:

{
  "$traceParent": "00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01",
  "$traceState": "dd=s:1",
  "$traceId": "0af7651916cd43dd8448eb211c80319c",
  "$spanId": "b7ad6b7169203331"
}

For an unsampled trace, which previously got nothing, the client writes only the new field:

{
  "$traceParent": "00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-00"
}

Upgrading

Consumers using the default ParentBased sampler now respect the producer's sampling decision, so events from unsampled traces no longer produce sampled consumer spans. This is the correct W3C behavior, but you might see fewer consumer spans if your producers sample aggressively.

If you registered an OpenTelemetry SDK with an alwaysOff sampler, event metadata is now stamped with $traceParent, where previously nothing was written.

Ref: DEV-1890

[linear-code]

DEV-1890