PAYARA-2924 NPE on JAX-RS Async-Server EE7 Sample

[Pandrex247]

If request tracing is turned on when running this sample, a NPE is thrown.
This is caused by the return happening on a separate thread, so the container filter gets a NPE when trying to get the access active span (as these are thread local).

This PR fixes this by saving the span context as an attribute of the InvocationContext object created by managed pools so that the span context can be propagated when setting up the thread context.

Threads from managed pools created external to Payara will not be traced however, such as those created by Jersey to handle timeouts.

This also adds the ability for OpenTracing to create traces itself (rather than requiring a trace to already be running), and includes a couple bits of cleanup.

[lprimak]

Have you tested with versioned applications? I think you will get a clash.
This is why my first stab at that "context"-y kind of stuff was by application name, but I went off that and started using component ID instead.
I think you are re-inventing the wheel here with maps and stuff and better off using JavaEEContextUtil

[Pandrex247]

I went with using this method as it's essentially how they suggest you do it in OpenTracing.

I'm not sure where I'd be getting a clash though, as the application name is only ever used for getting the Tracer instance, which is thread local anyway.
And if there was a clash, it's not strictly tied to this fix.
I may just be being blind though, so I'll give it a test.

[Pandrex247]

Jenkins test please

[payara-ci]

Quick build and test passed!

[arjantijms]

Have you tested with versioned applications?

Not yet, might look at that next version.