Fix request != 0 checking in the scalar paths of merge()

[akarnokd]

Requested amount could reach zero between the first check and entering the synchronized block where it has to be re-read in order to verify the scalar emission can really happen at that point; the new testMergeAsyncThenObserveOnLoop test failed with MissingBackpressureException after ~20 rounds on my i7 4770K.

This might or might not relate to the canary failure; if combined with retry(), it could have failed over and over, but I'm not sure where the worker retention might have happened.

[benjchristensen]

Is this urgent for release, or can it wait?

[akarnokd]

Yes, this is severe enough, especially if one merges high throughput asynchronous sources before observing them on a scheduler. Synchronous merges or small amount of values won't trigger the MissingBackpressureException.

There is another possible issue which affected the merge() version before. Due to the scalar optimization, it could reorder values from a source:

1. a value comes in but requested is zero, therefore, the value is queued,
2. the requested amount increases but it doesn't enter the emission loop yet,
3. another value comes in, finds the requested to be non-zero, successfully enters the emitting state and emits this second value while the first is still in the queue,
4. the requester also enters/signals the emitter loop and the queue is drained.

Apparently, users of merge() so far didn't really mind this occasional reordering in the output.