Re: [streams] Getting errored/closed reader, Auto-releasing reader, Forcible cancel() on a stream (#297)

OK, quick in-person huddle yielded the following proposal.

- `cancel()` method is on reader, and not on stream
- `pipeTo`, and any operations a developer might create (like `readableStreamToArray`), should get cancellation ability in whatever way promises get cancellation ability. Since they work internally by using `getReader()`, they can call `reader.cancel()` in reaction to cancellation requests.
- fetch cancellation ability has the ability to stop the flow of data at any time, even if the headers are already delivered and the body is locked. Since this is more disruptive, and can interfere with people who thought they had exclusive control, it should *not* work via the same cancellation path. Instead it makes the stream errored. This is identical to how, when the browser stops a stream (e.g. because the user pressed the "Stop" button or unplugged their internet connection or something), it will error the stream with an abort error of some kind.

This makes a lot of sense to me. Action items/takeaways:

- Revert `{ finished, unpipe() }` in that PR, pending future more general cancellable promise solution
- Keep `cancel()` on reader only
- Cancelling a fetch, in whatever form it takes, should error the stream (if it exists).
- A canceller approach is probably better for fetch() than a `fetchPromise.cancel()` approach. Since otherwise `fetchPromise.cancel()` would affect things after the promise has already settled. (Or, alternately, we would allow `fetchPromise.cancel()` to affect the fetch only before headers are retrieved---which is awkward.)

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/297#issuecomment-81417538