Add methods to ServiceInvocationContext for propagating context into callback invocations.

[anuraaga]

Currently, when writing an asynchronous service that does multiple RPCs, the RPC callbacks will likely be called with no ServiceInvocationContext.current() set. This is because the initial invocation removes the context right away to allow processing another event from the event loop, here

https://github.com/line/armeria/blob/master/src/main/java/com/linecorp/armeria/server/HttpServerHandler.java#L264

We need a mechanism for propagating the invocation context to when the RPC callbacks fire (and may trigger additional RPCs, callbacks, etc), otherwise context-dependent features (think zipkin) will not work.

This PR adds methods for propagating context into callback methods, including an executor that will do it automatically for any subitted tasks. In general, service code will want to to use this executor in calls like CompletableFuture.whenCompleteAsync. They probably already are using ServiceInvocationContext.eventLoop to make sure callbacks are called on the same thread, and this would replace that so they're on the same thread with the correct context.

[anuraaga]

Let me know if I should check the current context or something. As far as I would expect, eventLoop.execute() is guaranteed to execute the task at some time in the future after the current calling code has returned since it's all just one thread, meaning there's no way this could be set at this time.

[trustin]

Instead, you could get the current ServiceInvocationContext before creating a callback and access the context from the callback:

public class MyThriftServiceImpl implements MyThriftService.Iface {
    public void foo() {
        ServiceInvocationContext ctx = ServiceInvocationContext.current();
        ListenableFuture<Object> f = someAsyncClientLibrary.bar();
        f.addListener(() -> {
            ... do something with ctx ...
        }, someExecutor);
    }
}

Or.. am I missing something out?

[anuraaga]

And call ServiceInvocationContext.setCurrent in service code? That sounds wrong.

Again I'm mostly concerned with armeria breaking because of the lack of context for stuff like tracing, and having the client code having to call setCurrent or whatever sounds like a dangerous way to make that work.

[trustin]

And call ServiceInvocationContext.setCurrent in service code? That sounds wrong.

No. Just passing the context object as a field of a callback?

[anuraaga]

How would armeria client's use of current ServiceInvocationContext to stay on the thread work? And in the future opening a zipkin span in the context. Both of these happen in armeria and rely on setCurrent having been called. I think propagating inside an armeria executor makes the most sense for them to continue to work.

[anuraaga]

Specifically this code currently won't work in callbacks

armeria/src/main/java/com/linecorp/armeria/client/HttpRemoteInvoker.java

Line 150 in 1ffb8d0

private EventLoop eventLoop() {

[trustin]

callback -> object created by makeContextAware() ? How about rephrasing this so it mentions makeContextAware() and contextAwareEventExecutor()?

[trustin]

a -> an

[anuraaga]

Addressed comments

[trustin]

@anuraaga Thanks! Merged.