Enable access to context provider

[p-lambert]

Also:

• Add DefaultContextProvider#context= method

[palazzem]

I see the point, but in that case we're going to simply replace the way to do context propagation (the ThreadLocalContext is a specific implementation to get/set the propagation). I think it would be better to have a def context= that simply sets the @context.local to the given value (so it replaces the thread-local storage).

With the PR API we're having:

ctx = tracer.provider.context  # assuming we're not using the shortcut
tracer.prover.context = Datadog::ThreadLocalContext.new

My goal here is having:

ctx = tracer.provider.context
tracer.provider.context = Datadog::Context(...)  # you will do that in distributed tracing

The second approach is more symmetric and the API is just a "wrapper" to get/set the active Context regardless where it's stored.

What do you think?

[p-lambert]

humn, this is part of the API that still doesn't make sense to me. In my opinion, it really feels that the ThreadLocalContext is precisely a context provider! All it is doing is binding the context object to a thread-local variable, so it really feels that it overlaps with the provider responsibility. On the other hand, I don't understand what .local would mean for contexts other than the ThreadLocalContext.
I also find confusing that we we say ThreadLocalContext, because that object doesn't expose the same API that the Context does. Maybe ThreadLocalContext Should be merely a delegator around Context? I think the goal is make it transparent for the Tracer, right? I just don't agree/understand this interface Provider->ThreadLocalContext->Context
Long rambling here, lol. Maybe I'd understand this better if I knew future use-cases/implementations for these objects, but right now these abstractions don't make much sense for me.

[palazzem]

The final implementation we need is a Provider that returns the current active Context (or Span). I definitely agree that ThreadLocalContext is a level of indirection, so to me the goal here could be simply:

• DefaultContextProvider is the provider (as said in the name) that offers a way to get/set the current active Context
• DefaultContextProvider includes the logic of ThreadLocalContext that is a level of indirection and doesn't need to exist
• Context is left untouched

I think that ^^ makes more sense.

[p-lambert]

awesome! yes, that makes much more sense imo. Do you think we should "merge" the DefaultContextProvider and ThreadLocalContext in this PR, or leave it for a future one and just update the setter now? I'm fine with either.

[palazzem]

I'd prefer to do that in the PR where we're propagating the Span instead of the Context. Lot of changes here, I prefer a clean 0.8.2 without breaking changes (even if this one is "internal" and nobody should use it). Cool?

[p-lambert]

Perfect. Thanks!

[palazzem]

No breaking changes here, only the new setter so all good to me to ship with a minor release.