WIP: Baggage Propagation

[rachelyangdog]

What does this PR do?

• adds "baggage" as part of the default propagators
• creates a baggage propagator and adds inject and extract functionality
• properly encodes/decodes headers and drops excess baggage items and bytes
• adds logic to get baggage from the request context and adds it to the span in order to inject into the headers

Motivation

Reviewer's Checklist

• Changed code has unit tests for its functionality at or near 100% coverage.
• System-Tests covering this feature have been added and enabled with the va.b.c-dev version tag.
• There is a benchmark for any new code, or changes to existing code.
• If this interacts with the agent in a new way, a system test has been added.
• Add an appropriate team label so this PR gets put in the right place for the release notes.
• Non-trivial go.mod changes, e.g. adding new modules, are reviewed by @DataDog/dd-trace-go-guild.
• For internal contributors, a matching PR should be created to the v2-dev branch and reviewed by @DataDog/apm-go.

Unsure? Have a question? Request a review!

[datadog-datadog-prod-us1]

Datadog Report

Branch report: rachel.yang/baggage-prop
Commit report: c85eaed
Test service: dd-trace-go

✅ 0 Failed, 5237 Passed, 73 Skipped, 1m 47.69s Total Time

[pr-commenter]

Benchmarks

Benchmark execution time: 2025-02-07 22:24:50

Comparing candidate commit 35ccc89 in PR branch rachel.yang/baggage-prop with baseline commit dbfb8f2 in branch main.

Found 0 performance improvements and 6 performance regressions! Performance is the same for 53 metrics, 0 unstable metrics.

scenario:BenchmarkHttpServeTrace-24

• 🟥 allocated_mem [+297 bytes; +327 bytes] or [+3.087%; +3.389%]
• 🟥 allocations [+10; +10] or [+12.346%; +12.346%]
• 🟥 execution_time [+1.217µs; +1.391µs] or [+7.546%; +8.628%]

scenario:BenchmarkStartRequestSpan-24

• 🟥 allocated_mem [+8 bytes; +8 bytes] or [+3.226%; +3.226%]
• 🟥 allocations [+1; +1] or [+16.667%; +16.667%]
• 🟥 execution_time [+46.636ns; +47.644ns] or [+12.695%; +12.969%]

[mtoffl01]

On the right track, but the new code in StartRequestSpan is causing us to do tracer.Extract twice when we could just do it once. At the same place where we process span links after trace extract (line 127 on your branch, currently), we can also populate a baggagemap with the baggage items found from the returned spanParentCtx. Then, we can push those items onto the request context that we are going to propagate after line 141.

[darccio]

LGTM. Approving this, given @mtoffl01 is going to be applied too.