Expose utils to parse trace state

[lmolkova]

Is your feature request related to a problem?
Some custom samplers need to access tracestate to make sampling decision (this is on of the ways to interop with legacy custom correlation protocols). Currently such samplers would have to parse tracestate on their own.
Let's say sampler whats to check certain flag value in tracestate: 'sampling.priority=0.5'

• Sampler implements SamplingResult ShouldSample(in SamplingParameters samplingParameters)
• SamplingResult has ActivityContext which has TraceState string
• Tracestate parsing methods are not exposed and samplers should parse it on their own

Describe the solution you'd like.

• Expose TracestateUtils and add static public bool TryExtractTracestate (string tracestateString, out IEnumerable<KeyValuePair<string, string>> tracestate)

Describe alternatives you've considered.

• let it be (custom implementations will likely be error prone and less efficient). At the same time it's likely samplers can do cheaper parsing of the single flag they need.
• Add Tracestate type and have static parsing methods on it. I believe we should keep public API area smaller and we pushed hard in the past to remove any types that are not essential, so this seems to be an overkill.
• Expose SpanContext(ActivityContext) or add SpanContext(traceid, spanId, flags, isRemote, tracestateString)ctor: not great since samplers don't need SpanContext, just the tracestate portion of it

[cijothomas]

namespace System.Diagnostics
{
    public readonly partial struct ActivityContext : IEquatable<ActivityContext>
    {
+        public static bool TryParse(string w3cId, string? traceState, out ActivityContext context);
    }
}

The above is coming in .NET API. It'll do entire ActivityContext, not just tracestate portion.

[lmolkova]

@cijothomas yes!!!

[lmolkova]

been thinking about it and decided to reopen:
Yes. I can use ActivityContext.Parse and then create SpanContext out of it and iterate over tracestate, but actually the only thing I need is parsed tracestate.

So this seems to be a reasonable workaround, but parsing traceparent is an overhead that ideally should be avoided for the sake of perf.

[martinjt]

I don't think we have intentions to add this. You can parse the whole traceparent and tracestate using the TextMapPropagator, or through the Activity methods.

If you feel strongly that it should be provided by OpenTelemetry, then please reopen. I don't think this is a requirement for the SDK via the specifications though.