Refactor existing code to propagate context.

[tomas-langer]

Follow up issue for #596
Refactor existing implementations to make sure context is correct created and propagated when switching threads.

• webserver (Context integration #675)
• fault tolerance (Review Helidon context propagation in FT  #678)
• security
• grpc (Create helidon context in gRPC server implementation #698)
• jersey client
• jersey support

[tomas-langer]

The expected stuff to find in the context (to be documented).
This is proper magic and as such we should minimize this and properly document such behavior. Nevertheless this is a much needed magic - we have trouble propagating any information otherwise, as we have no chance to use ThreadLocals that could otherwise be used within a component.

Request context (coming from Web Server or gRPC Server or any other originating component):

• io.opentracing.Tracer - the configured tracer (this may be also a no-op tracer if none is configured)
• io.opentracing.SpanContext - the span context of the current request
• io.helidon.security.SecurityContext - the information about current subject, security context is optional and only present if security is configured

Recommended usage of these:

Tracer tracer = context.get(Tracer.class)
                    .orElseGet(GlobalTracer::get);

Tracer.SpanBuilder spanBuilder = tracer.buildSpan("new-span");
context.get(SpanContext.class).ifPresent(spanBuilder::asChildOf);

[tomas-langer]

Initial implementation for Web server and FT is done in #675

[tomas-langer]

This task is finished - gRPC, FT, Jersey and security all use context propagating executor services or run tasks in context.