Context

Fix a race condition bug with RenderResultReadable.

What is the bug?

The RenderResultReadable class lets us efficiently stream synchronous or async iterables. It's architecture is designed to be as optimal as possible, so synchronous streams go fast and have minimal overhead from the async handling.

Our RenderResultReadable.prototype._read implementation is async, allowing us to await values in the stream.
From Node.js documentation: "_read() will be called again after each call to this.push(dataChunk) once the stream is ready to accept more data."

This is also the behavior back to Node.js v10.

What happens for the test case below (without the fix) when we are reading from the stream:

new RenderResultReadable([
    'a',
    new Promise((res) => setTimeout(res, 50)).then((_) => ['b']),
    'c',
]);

1. Node.js calls _read(). We synchronously push('a').
2. Our _read encounters the promise and awaits the promise.
3. Node.js calls _read(), and we synchronously push('c'), then we loop and synchronously call push(null) terminating the stream.

Thus the promise is skipped.

Fix

Once _read() is called, it will not be called again until readable.push() has been called. This makes it safe for us to noop a _read() call while a Promise is waiting. Then once that promise resolves, it will result in push() being called with the resolved data and we're back in a consistent state.

Test plan

I added two tests that reproduce without the _waiting flag.