support asynchronous responses to unary requests.

[f355]

This adds support for asynchronous responses to unary requests, by analogy with gen_server:reply/2.
A usage example:

my_service_handler(Ctx, Req) ->
    spawn(fun() ->
                  Resp = do_some:heavy_lifting(Req),
                  ok = grpcbox_stream:unary_reply(Resp, Ctx)
          end),
    {noreply, Ctx}.

Please let me know what you think, and I'll add the docs and tests if the implementation looks good.

[tsloughter]

Curious what your use case is for this? Are there things the stream can be doing for a unary request while a response is waiting to be sent?

[f355]

it's pretty simple, I'm writing a proxy where the other side is asynchronous. I'm forwarding the request to the other side and storing the context elsewhere, the response eventually arrives and all I have to do is look up the context and call grpcbox_stream:unary_reply/2.

I know I can achieve the same behavior by blocking the handler in receive, storing its PID and !-sending the response to it, but that looks pretty ugly.

[sebastiw]

Any updates on this @tsloughter ? 🙏

[tsloughter]

I hope to get these PRs merged. I'm good with the feature, just wary of touching unary client pieces until this bug is figured out open-telemetry/opentelemetry-erlang#459

Unary stream processes are hanging around.

[lixen-wg2]

I just cleaned up our fork and saw that we have made changes in the area.

This is our current implementation of the asynchronous support.
main...omnicate:grpcbox:async-unary-response

Should I open a new PR and close this one?