Propagate context

[iNikem]

Partially addresses #507 .

First cut on propagating full Context instead of just Span. Two major things are not done yet:

• io.opentelemetry.auto.bootstrap.instrumentation.decorator.HttpServerTracer#attachSpanToRequest should be redone to something like propagateContext. But as new context is not created inside startSpan method, that propagateContext should be moved, made public etc...
• io.opentelemetry.auto.bootstrap.instrumentation.decorator.HttpServerDecorator#SPAN_ATTRIBUTE. I have a temptation to live it be. The whole HttpServerDecorator is deprecated and is to be replaced by HttpServerTracer anyway.

Probably something else is missing

[trask]

this change looks really good

a couple suggestions below

[trask]

i think it makes sense to end the span here, at the beginning of onCompleted

[iNikem]

My line of thought was the following: in comes a request, when a response is ready AsyncCompletionHandler will be called. I think we want to end the request processing span after that handler has completed its job. So that if it fails or takes long time, that would be recorded in the captured span. No?

[trask]

i think the CLIENT span timing and success are supposed to match the HTTP timing / success as closely as possible

i don't see this called out in the spec, but there's some related discussion here: open-telemetry/opentelemetry-specification#591 (comment)

[anuraaga]

Approach LGTM, definitely nicer to propagate context than span

[trask]

💯