Add Datadog propagator

[majorgreys]

This adds DatadogFormatfor extracting and injecting trace contexts with Datadog-specific headers.

[toumorokoshi]

LGTM! From a code perspective.

I raised a couple side questions around DD and other propagators in practice.

Another question that comes to mind: for an ecosystem that uses purely OT, how will the DD_ORIGIN be set in the first place? Will an http client be responsible for adding the field, if it doesn't already exist?

I see that all the code here is strictly propagating the DD_ORIGIN value, rather than originating it.

[toumorokoshi]

is this a utility method available in the API? I know it's good to not couple too heavily, but this feels like boilerplate for propagators.

[majorgreys]

I see it in opentelemetry.correlationcontext.propagation as well as the b3 code. Could be pulled out as a generally applicable http util method. Suggestions on where that might be? Could do this refactoring in a follow-up PR.

[toumorokoshi]

correlationcontext is interesting. I don't have a strong opinion, maybe opentelemetry.propagation.utils?

[toumorokoshi]

an aside, but how is the origin key used by DataDog? I wonder if this is something to raise up to the specification SIG, if there's value in another key that is not appropriately propagated.

This also raises an issue for those who want to use open propagation specifications and DataDog at the same time. If one does want to use DataDog in it's full capacity, I presume that will require the setting of the DD_ORIGIN value. For those want to switch to DataDog despite using an existing propagation spec, they may not get the full functionality unless they switch all services to use this propagator.

Thoughts?

[majorgreys]

This is used to link traces to Synthetics tests: https://docs.datadoghq.com/synthetics/apm/#how-are-traces-linked-to-tests

As for using Datadog alongside an open propagation specification, I had been thinking that this be accomplished by adding the Datadog format to the composite propagator. Here's how I did it for a test app:

    global_httptextformat = propagators.get_global_httptextformat()
    if isinstance(
        global_httptextformat, propagators.composite.CompositeHTTPPropagator
    ) and not any(
        isinstance(p, DatadogFormat) for p in global_httptextformat._propagators
    ):
        propagators.set_global_httptextformat(
            propagators.composite.CompositeHTTPPropagator(
                global_httptextformat._propagators + [DatadogFormat()]
            )
        )
    else:
        propagators.set_global_httptextformat(DatadogFormat())

Appending to the global format could be something that's added to the API.

All services would have to have the Datadog propagator added, though that could be part of enabling the Datadog exporter for these services.

@toumorokoshi Any problems you see with that approach?

[toumorokoshi]

The composite approach makes sense as a transition, I was referring more toward using open propagation exclusively.

But it sounds like that would work perfectly fine here, the only caveat is the missing DD_ORIGIN propagation, which isn't needed for all the features.