trace: ParseTraceState ignores duplicated tracestate keys

[pellared]

Inspired by open-telemetry/opentelemetry-dotnet#4937 (kudos to @Kielek)

The change is a follow-up on the changes done in the Trace Context Specification:

• https://www.w3.org/TR/trace-context/#combined-header-value (currently not described)
• https://github.com/w3c/trace-context/blob/551a5b0855171281e98b4c2a814bf9e1f837cd53/test/test.py#L563-L568
• https://github.com/w3c/trace-context/blob/551a5b0855171281e98b4c2a814bf9e1f837cd53/test/tracecontext/tracestate.py#L61-L63
• Specify uniqueness of tracestate keys as the sender's responsibility w3c/trace-context#477

I also created for completeness: w3c/trace-context#547

[codecov]

Codecov Report

Merging #4638 (b2f83be) into main (5dff273) will decrease coverage by 0.1%.
The diff coverage is 100.0%.

❗ Current head b2f83be differs from pull request most recent head 5f4ac4f. Consider uploading reports for the commit 5f4ac4f to get more accurate results

@@           Coverage Diff           @@
##            main   #4638     +/-   ##
=======================================
- Coverage   81.3%   81.3%   -0.1%     
=======================================
  Files        222     222             
  Lines      17682   17682             
=======================================
- Hits       14391   14389      -2     
- Misses      2991    2993      +2     
  Partials     300     300             

Files	Coverage Δ
trace/tracestate.go	100.0% <100.0%> (ø)

... and 22 files with indirect coverage changes

[MrAlias]

This is a link to W3C unit tests. Can you instead link to the part of the W3C specification that describes this behavior?

[pellared]

I have not found anything better than the test code in the specification that describes it. See: https://github.com/instana/trace-context/blob/master/spec/20-http_request_header_format.md

[pellared]

I created w3c/trace-context#548

[pellared]

Do you have any other suggestion or can this comment be resolved?

[MrAlias]

It seems like this behavior is only mentioned in the editor draft of the W3C trace-context as optional. This PR seems premature given that unreleased state.

[pellared]

Changing to draft

[pellared]

It seems like this behavior is only mentioned in the editor draft of the W3C trace-context as optional.

For me even the editor draft does not clearly defines this behavior thus I created w3c/trace-context#548