Propagate sample rate through tracestate

[russcam]

This commit propagates the sample rate of the APM agent through the tracestate header, and uses the sample rate received in incoming tracestate as the sample rate for non-root transactions and spans.

Introduce TraceState type to model tracestate, allowing incoming headers to be added and sample rate to be set. Move TraceState validation from TraceContext onto TraceState.

Obsolete TryDeserializeFromString and SerializeToString on DistributedTracingData in favour of a method that accepts both traceparent and tracestate, and properties that get the traceparent and tracestate text headers, respectively.

Change Transaction and Span SampleRate to double? to allow a value to be omitted when incoming Trace context does not contain a tracestate header or the header does not contain the es vendor s attribute.

Closes #1021

[apmmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Build Cause: Pull request #1147 updated

• Start Time: 2021-03-25T23:22:06.676+0000

• Duration: 56 min 4 sec

• Commit: 97aa519

Test stats 🧪

Test	Results
Failed	0
Passed	19089
Skipped	80
Total	19169

Trends 🧪

[gregkalapos]

I have a bit of a mixed feeling about adding [Obsolete()] to the DistributedTracingData public APIs.

For HTTP we propagate the tracestate out of the box and I'm not sure how relevant it is to propagate this value manually for other use cases. I usually tend to prefer not to change public API. I'd totally agree with this PR if we'd start out new, but I'm not sure the benefit of adding the ability to propagate tracestate manually outweighs technically breaking user code (sure, with the attribute we don't break directly, but long term users need to change user code).

I'll ask around on what other agents do.

[russcam]

In its current form, DistributedTracingData only exposes traceparent and not tracestate. The Elastic APM agents may be used with other systems that require manual propagation of traceparent and tracestate, but they would only be able to get the former and not the latter, which on the surface seems limiting; for example, System.Diagnostics.ActivityContext exposes TraceState.

Let's sync to discuss.

[russcam]

Would you mind taking another look at this, @gregkalapos? I think it's good to go now, with the changes in 9c6d5f3, following our discussion.

[gregkalapos]

LGTM 👍

Just to document here one thing I was interested in and played with:
Activity also propagates the traceparent and tracestate in HTTP requests - so it writes the exact same HTTP headers as we do. I did some testing and it seems that always our values end up being in those headers. We specifically check in HttpDiagnosticListenerImplBase.cs if those hears are already present and only write those if they aren't. As it seems this is all fine and works as intended.