Suggested new implementation of reverse call dispatcher.

[jakhog]

It is not tested, and I have not done any effort on checking specs.

It is probably worth it to have a second pass on places where exceptions can get thrown as well.

The idea of usage is that in a gRPC server implementation, in a server call handle method you would:

1. Get a IReverseCallDispatcher from the IReverseCallDispathers, by giving it the two streams, and a bunch of delegates to get and set the correct properties on the messages.
2. Await the receiving of the Connect arguments from the client by calling ReceiveArguments(). If it returns true, you got arguments in the Arguments property, if it returns false something wrong happen and don't do anything more. Returning from the handler will close the connection.
3. Check the arguments and perform any validation, and then choose to either Accept or Reject the connection, in both cases with a response to the client.
   • Rejecting the connection just writes the response, and does nothing more, so the connection is closed.
   • Accepting the connection writes the response, then starts an infinite loop reading responses back from the client.
4. After that, the IReverseCallDispatcher can be passed to other components, which can then use Call with a request, and await the task to recieve the correct response from the client.

A thought that occured to me now, is that it is important to send any requests to the client before the connect response is sent. So if the call dispatcher is passed to other objects before it is accepted, we might need to initialise the semaphore with a (0), and release it again in Accept and Reject.

┆Issue is synchronized with this Asana task