Streams: test whether pipe stop pulling on abort

[MattiasBuelens]

See whatwg/streams#1208 for the accompanying spec change.

These tests demonstrates one way how pipeTo() can inadvertently drop a chunk continue reading for too long.

1. The source starts with one chunk 'a' in its queue.
2. The destination has highWaterMark = Infinity, so writer.ready is always resolved.
3. We start a pipe with preventCancel = true and a given AbortSignal.
4. The pipe reads the first chunk from the source's queue. It starts writing it to the destination.
5. The pipe starts a read request for the second chunk, which is not yet available.
6. We abort the AbortSignal.
7. We enqueue a second chunk 'b'.
8. The pending write (for 'a') completes.

Expected behavior:

• The pipe promise rejects with the signal's abort reason.
• The destination receives only chunk 'a'.
• The source's queue contains the chunk 'b'.

Actual behavior:

• The pipe promise rejects with the signal's abort reason.
• The destination receives both chunk 'a' and 'b'.
• The source's queue is empty.

[domenic]

inadvertently drop a chunk.

Is it dropped? Or is it just sent to the destination over-aggressively?

[MattiasBuelens]

Oops, you're right. 😅 I was initially testing with erroring the writable stream to stop the pipe, but in the end I went with aborting it using a signal instead.

I think it's possible to trigger something similar with an errored writable stream, but I think we can solve that with your suggestion in whatwg/streams#1207 (comment) to synchronously check the destination's state.