Register tracer to GlobalTracer

[pavolloffay]

@jpkrohling had a great question: why the tracer is not registered into GlobalTracer?

At the moment spec only defines that the tracer should be available via CDI. Here is some documentation of GlobalTracer https://github.com/opentracing/opentracing-java/tree/master/opentracing-util#globaltracer

Benefits

• implementation of tracer provider could be standardized e.g. smallrye project could provide a basic implementation. The producer would provide GlobalTracer.get() as a bean. Configuration and tracer resolution would still be vendor specific.
• GlobalTracer is directly provided by OT API and nicely fits into ecosystem of instrumentations

Drawbacks

• TCK injects tracer and invokes methods to get reporterd spans https://github.com/eclipse/microprofile-opentracing/blob/master/tck/src/main/java/org/eclipse/microprofile/opentracing/tck/application/TracerWebService.java#L95 this would not work as global tracer wraps the tracer. unwrap on the tracer should solve this problem Add unwrap to interfaces opentracing/opentracing-java#282.
• as the OT readme say https://github.com/opentracing/opentracing-java#accessing-the-tracer CDI should be a preffered way how the tracer is shared.

[jpkrohling]

The current implementation of the GlobalTracer stores the tracer in a static field, making it tricky to support different concrete tracers for different applications on a single JVM (which is the usual case for application servers).

One possible solution is for runtimes to provide their own tracers and register them with the GlobalTracer. This custom tracer would then retrieve the concrete tracer from, say, the servlet context. This would then require a standard to be set for the servlet context attribute name to store the tracer.