ddtrace/tracer: fix calculation of `tracestate` length
What does this PR do?
This changes how the tracestate limit is calculated as it wasn't accurate (too restrictive). This will allow for a couple of extra characters to be added to the dd tracestate value.
The tracestate can be composed of various list-member entries such as dd=s:1.
Here dd is the key of the list-member and s:1 is the value (the = is just a separator character).
Per the W3C tracecontext documentation both the key and the value can be 256 characters long. Our RFC is actually a bit vague here, but the examples do not include the dd= as apart of the length consideration.
Previously, the dd= string was being included in the calculation for the value, this fixes that.
Previously the ; necessary for adding an additional propagated tags wasn't being account for, this fixes that.
Note: that the way this was before it wasn't actually going over the 256 character value limit as it was including dd= as a part of that length - it would have always been below the limit.
It may be easier to look at the two commits here individually. The first commit demonstrates the issue with ;, the second updates it to ignore dd=.
I'm also up for reverting the commit that excludes dd= from the length consideration as the RFC and W3C documentation isn't entirely clear on this and we may want to validate how the other libraries have handled this limit.
Motivation
Ran into a failed test when working on #2579 where the length was too long, which was the ; issue and then noticed that it was including dd= in the length as well.
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 Datadog employees:
- [ ] If this PR touches code that handles credentials of any kind, such as Datadog API keys, I've requested a review from
@DataDog/security-design-and-guidance. - [ ] This PR doesn't touch any of that.
Unsure? Have a question? Request a review!