NettyMessageService should accept an event loop and thread factory at construction time

[Benjamin Berman]

Is your feature request related to a problem? Please describe.

Using vertx together with atomix works very well for me. However:

1. vertx and atomix use their own event loop groups.
2. Because vertx is the application, most of the time I'm rescheduling an atomix event to be processed on a vertx event loop thread (i.e., vertx.runOnContext(v->doSomethingWithAtomixResult(atomixResult))).
3. Both store context on threads they create in their own thread factories.

Describe the solution you'd like

Use FastLocalThreadStorage to store the AtomixContext, then accept a NettyEventLoopGroup as a configuration argument for the MessagingService (the only place this really matters).

Describe alternatives you've considered

Using Context context = Vertx.currentContext(); then using context.runOnContext() in atomix callbacks.

Additional context

Because I also use fibers, I got weird bugs with Hazelcast all the time so that's why I switched to Atomix. Thread local buffer pools and all that madness.

[Steffen]

+1

We would need this aswell.

[Johno Crawford]

@doctorpangloss @eckig happy to review a pull request.