feat(tracing) [DSC] Dynamic Sampling Context continuation

[smeubank]

Describe the idea

As a server side platform one ruby applications instrumented with the Sentry SDK should continue to propagate dynamic sampling context data to all outgoing requests.

The SDK should extract Dynamic Sampling Context from incoming requests, and propagating DSC to downstream SDKs.

Requirement:

When a Ruby application receives a request which has baggage attached with sentry values,
It shall propagate those same value in further outgoing requests
so that contextual data is preserved across the continuation of trace

what should be sent?

baggage header

• sentry-trace_id
• sentry-public_key
• sentry-sample_rate
• sentry-release
• sentry-environment
• sentry-user_id
• sentry-user_segment
• sentry-transaction

Envelope Header

• trace_id (string)
• public_key (string)
• sample_rate (string)
• release (string)
• environment (string)
• user_id (string)
• user_segment (string)
• transaction (string)

where should it be sent?

• in dynamic sample context (by baggage)
• in the envelope header
• meta data (was/is being done in JS to be check if still necessary)

Example:
Here is an example from the Sentry UI, where the implementation has already begun on the latest versions of the JS SDK. A request from the front end to a down stream applications includes in the request header baggage

Why do you think it's beneficial to most of the users

This ensures that further downstream applications connected in a distributed trace will contain all contextual data required for dynamically sampling based on upon the contextual data from the head of the trace.

Possible implementation

Implementation has already begun (at the time of this creation) on JS and Android. Refer to the SDK Developer documentation for further information

For full up to date requirements according to SDK Developer specifications please see the associated documentation.

Dynamic Sampling Context

Original PR for full context
Add spec for Dynamic Sampling Context #613