Skip propagating empty W3C tracestate header on outbound spans

[davidefrageri]

Summary

OpenTelemetryTraceIdUtils#getDistributedTraceContext unconditionally adds the tracestate entry to the distributed-trace context, even when the encoded TraceState returned by W3CTraceContextEncoding.encodeTraceState is the empty string. When that map is later applied to an outbound HTTP request (for example by the http:request operation propagator) the runtime emits a bare tracestate header on the wire.

Per the W3C Trace Context specification, tracestate must contain at least one list-member, so an empty header is
non-conformant. Several intermediaries (some L7 load balancers, API gateways and OTLP collectors we hit in production) reject the whole request with 400 Bad Request when they encounter it, which breaks downstream calls made
from a Mule flow that does not happen to have any vendor entries on its trace state.

What's changed

OpenTelemetryTraceIdUtils#getDistributedTraceContext now:

1. Computes the encoded trace state into a local variable (no behavioural change in either branch of the existing isAddMuleAncestorSpanId check).
2. Only puts the tracestate key into the returned context map when the encoded value is non-null and non-empty.

The traceparent header is still emitted unconditionally — only the optional tracestate companion is suppressed when it would otherwise be empty. The inbound side (MutableMuleTraceState.getMutableMuleTraceStateFrom) already treats a missing or empty tracestate entry as "no remote trace state", so this is symmetric and does not change how propagated state is parsed.

Steps to reproduce (before the fix)

1. Configure a Mule app with http:request and OpenTelemetry tracing enabled (mule-opentelemetry-module / built-in tracer exporter).
2. Trigger a flow whose current span has no vendor entries on its TraceState (the common case for a freshly created root span).
3. Capture the outbound HTTP request, e.g. with tcpdump/mitmproxy/the target service's access log.
4. Observe the bare tracestate: header alongside traceparent: 00-….

After the fix only the traceparent header is sent in that scenario; once a non-empty TraceState is present (incoming W3C tracestate with vendor entries, or the Mule ancestor span id added via isAddMuleAncestorSpanId) the header is emitted as before.

Scope of the change

• Files: modules/tracing/mule-tracer-exporter-impl/.../OpenTelemetryTraceIdUtils.java
• No public API change, no behavioural change for non-empty trace states.
• No new dependencies.

[salesforce-cla]

Thanks for the contribution! Unfortunately we can't verify the commit author(s): Davide Frageri <d***@d***.h***.t***.it>. One possible solution is to add that email to your GitHub account. Alternatively you can change your commits to another email and force push the change. After getting your commits associated with your GitHub account, sign the Salesforce Inc. Contributor License Agreement and this Pull Request will be revalidated.

[salesforce-cla]

Thanks for the contribution! Before we can merge this, we need @davidefrageri to sign the Salesforce Inc. Contributor License Agreement.