I'm trying to write code that uses MongoChangeStream but also minimises the amount of blocking.

Currently if you have a MongoChangeStreamCursor and call tryNext() it will either return immediately with the next in batch, or if it doesn't have such an item it will contact the server to see if it has more items. In the case where nothing is available this will block for the maxAwaitTimeMS. 

I propose adding a getNextInBatch() api point to MongoChangeStreamCursor. This will return the next in the batch if it's available but if it's not available it will not cause a delay.

-------

My use case is that I'm trying to listener code that handles batches of work. It's tempting to repeatedly call tryNext() on the ChangeStreamCursor until it returns null, then handle all the objects it did return. However if the queue is being appended to then tryNext() will forever return objects. Whilst I can batch this, there's no way to align the batches that I handle with the batches fetched from the DB, which causes extra chat / small inefficiencies in the process.

The code change looks relatively simple, so if you'd be open to user submitted patches please say!

Thanks!!