Make reactive stream reading non-blocking

[rickardoberg]

The current readStreamReactive implementation is not reactive at all, since the backpressure is not sent to the server. Instead the server sends messages as fast as possible and there is a blocking loop in ReadSubscription. If you have a 1000 subscriptions that are consuming slower than the server is sending, then that translates into 1000 blocking threads.

This PR changes so that the client properly uses backpressure by sending requests to the server when available. It amortizes the cost of the call to batches of 512 (i.e. if client requests Long.MAX_VALUE then only send out requests for 512 at a time), and topping it up if it goes below 512*3/4 (i.e. don't allow outstanding requests to reach 0 as that would introduce an unnecessary delay), but those numbers are just for illustrative purposes.

With this change a client that makes 1000 readStreamReactive subscriptions and is not able to consume the events fast enough will not create 1000 threads.

[CLAassistant]

All committers have signed the CLA.

[YoEight]

Hey @rickardoberg and thank you for that early Christmas present!

I only have a few remarks so far.

[rickardoberg]

You're welcome! And if you're feeling the mood, if there's a way to also add that the reactive stream does not close when there are no more events (i.e. it's a catch-up subscription) that would be FANTASTIC. Then the reactive stream API becomes the perfect way to integrate with the server.