First-class support for trace propagation across threads

[marcotc]

We currently support traces that span across multiple threads using the follow pattern:

parent_span = Datadog.tracer.active_span
Thread.new do 
  Datadog.tracer.trace("my.threaded.work") do |threaded_span|
    threaded_span.parent = parent_span
    # Threaded work goes here
  end
end

Despite parent_span and threaded_span having distinct thread-local contexts, this pattern works because we are manually setting the parent of the first span in the new thread with parent_span. The two distinct contexts will have their own spans and the backend will eventually stitch them back together into one large trace.

We should create an intentionally designed interface to provide threaded tracing. The current "support" is completely manual, and requires understanding of the internals of the tracer.

Ideally, transparent support would be achieved where all threads created from an existing tracing context get associated with the parent trace, but this might not be feasible. Consider the scenario where we spawn long-running threads:

def start_workers
   @workers.each(&:new_thread)
end

If a tracing context is active when start_workers is called, all work performed inside the worker threads will be associated with one very large trace if we have automatic context association.

A selective way to enable automatic propagation during the execution of a block could work to address this issue:

Datadog.tracer.active_span.thread_propagation = true

# or

Datadog.tracer.trace(..., thread_propagation: true) do # could also be configured to default to `true` instead
# ...
end

These are just suggestions on a possible approach.

[marcotc]

The continue_from argument added to Datadog::Tracing::Tracer#trace as well as the new method Datadog::Tracing::Tracer#continue_trace! allow for full support of async execution now.

These features were released in v1.0.0.