This bug is for the WPT tests for error propagation in response-error-from-stream.js

I was working nearby in Bug 1773237, and thought I would try to figure out what's going on here. I have an explanation, but unfortunately the fix isn't clear for me. This bug serves both to track the errors, as well as provide a diagnosis of what's going on.

The test cases test for a Response built around a ReadableStream with a start or pull error, ensuring that the error generated by the stream is propagated through various Response methods.

Tracking this down, it seems out current implementation of Response can't really do this properly. There's a pernosco trace here; but the general gist of what's going on is as follows:

1. When the stream read is attempted, we run the ReadRequest's errorSteps here, which because this is a FetchReadRequest means we run the FetchStreamReader::ErrorSteps, which totally discards the value provided. This is the proximate cause. However, it continues to be worse.

2. If you were to modify CloseAndRelease to actually propagate the value, you'd still not correctly report the error. That's because inside CloseandRelease, the error isn't triggered by the cancel promise (which is the root cause of Bug 1773237). Instead, the promise is rejected ultimately through the call to mPipeOut->CloseWithStatus. Through a complicated chain of causality, the promise returned from the ResponseBindings is actually rejected here, in BodyConsumer::ContinueConsumeBody. At this point, we've very far from the stored error passed to the FetchStreamReader::ErrorSteps, and it's deeply unclear how you'd communicate this through the chain of values that currently is totally built around a single nsresult value as the error.