Add support for client and server message buffering

[jvican]

(work-in-progress)

One of the current problems with our implementation is that request is
only called when the downstream consumer finishes the processing of a
message received from the server.

That is, if the server sends 10 messages on the same pipe and then the
client consumer is busy processing the first message, the other nine
messages will not be populated in the observable and might not even
reach the client grpc netty buffer. Only when the client finishes
processing the first message, it then calls request, processes another
message, and the same pattern continues where every message is pulled
right before it's going to be processed and not before that. This means
there is obviously a performance penalty and that such behavior can
change the way the consumer processes messages that can be sent or
processed in parallel, resulting in unexpected user semantics.

This commit uses asyncBoundary to fix this problem and have monix-grpc
populate an internal buffer with as many messages as they fit, while
still allowing the consumers to process these messages individually
without waiting to completely fill the buffer. If the server sends more
messages than they fit in the buffer, then asyncBoundary stops
consuming messages from the grpc source and consequently stop running
request calls, so the grpc runtime doesn't call onMessage anymore
until the messages in the buffer are processed downstream.

This behavior is great because the messages processed by onMessage are
added to a hot observable and asyncBoundary gives us all the benefits
of a backpressured source without actually using that source. As a
result, this means our hot observable will never grow larger than our
buffer because onMessage is only called when request is called.

So this simple solution actually gives us the semantics we want. The
following PR is built on top of this simple mechanism.

This is a work-in-progress PR, here's the things I'm currently
working on adding:

• Replicate the same implementation on the server call options
• Add a battery test similar to the one found in reactive-grpc
• Add a low tide argument to the client and server options
• Consider calling request with N messages instead of 1 if needed

I'm actively working on this PR so I'll add these changes shortly.

[borissmidt]

One thing that is not clear to me yet is how you set this ServerCallOptions.
Is meant to be set while registering the Api to the GrpcServer?

[borissmidt]

I think using the default values would make it easier to follow the code instead of using Option.
I.e. bufferSize can be None == 0 buffer or no buffer but
No compression is
Compressor.Identity the default could be Compressor.Gzip
enabledMessageCompression should be either true or false, having true false and None is a bit weird.