Migration of CDI contextual beans into new threads

[spericas]

Additional code is provided to not only active the request scope in the new thread but also migrate the beans in request scope. This is done according to the Weld documentation on context migration.

A new test shows how a request-scoped bean created in thread A is the same bean available in thread B using FT's @Asynchronous annotation. Note that the request-scoped bean in thread A needs to be accessed for its proxy to be created and migration into thread B to be successful.

Bean migration is one directional: from thread A (original request thread) to thread B and not the other way around. Application developers are responsible for properly synchronizing access to these beans that can potentially be accessed from multiple threads.

Issue #3319

[ljnelson]

Haven't even looked at this but I know that Weld does context propagation; you may want to double-check to see if one of its methods can help here so future bugs end up living where they're supposed to. (These methods may not be available in the version of Weld that Helidon uses; not sure. I just didn't want to lose the thread, so to speak.)

[spericas]

@ljnelson That's exactly where I got my Inspiration, that link. I've adapted their code for the migration process, excluding the other scopes they show there. Interestingly, Jersey has similar code in WeldRequestScope, however, they don't actually call clearAndSet ever, which sees very strange. For that reason, I've decided to do this by hand in Helidon instead of leveraging that Jersey class.

Could you think of a better way to do this migration than what is shown in this PR?

[tomas-langer]

@spericas is this something specific to Fault tolerance? Could we use the same code to have a general way of enabling request context in any asynchronous code when using CDI?

[tjquinno]

Go!