OpenTelemetry: Decide whether the ambient Activity should be propagated in headers when Otel is not enabled on the endpoint

[lailabougria]

Describe the suggested improvement

Is your improvement related to a problem? Please describe.

Currently, in a send-only endpoint that doesn't have OpenTelemetry enabled, any outgoing message will still be enriched with the traceparent header with the Activity.Current.Id if a current activity is available.

The question is whether that's the desired behavior. Given that OpenTelemetry is not enabled on the (send-only)endpoint, one could argue that that's a choice not to propagate tracing info through headers.

Due to this behavior, there's currently no way to avoid the traceparent header from being added to outgoing messages when there's an ambient activity.

Describe the suggested solution

Describe alternatives you've considered

Alternative 1: Modify the default behavior so that when OpenTelemetry is not enabled on the endpoint, no traceparent header is ever added to the outgoing messages. However, in the context of an incoming message, the outgoing message should propagate the traceparent header to respect the previous propagation decision.

Alternative 2: Keep the default behavior, but provide an opt-in setting to avoid the traceparent header from being added on outgoing messages (unless it was already there in the incoming message, if running in the context of an incoming message).

Alternative 3: Keep the status quo.

Additional Context

No response