[streams] Do writable streams need separate signals for write-success vs. write-accepted? (#316)

Spawned from https://github.com/yutakahirano/fetch-with-streams/issues/30.

The premise of the current writable stream design is that it's important to signal two things to the producer:

1. Whether a given write succeeds or fails
2. Whether the stream's internal queue, as determined by its strategy, is getting full (backpressure).

This manifests in the current API in two corresponding ways:

1. The promise returned by a call to `write()`
2. The stream's `state` property (`"waiting"` vs. `"writable"`) and `ready` promise. (Although, this would likely be revised in light of #301.)

Many "functional" writable streams (known as "generator interfaces" in [GTOR](https://github.com/kriskowal/gtor/) or "observers" in Rx-land) only supply the latter, and do so via the promise returned from (their version of) the write method, which fulfills when the stream is ready to accept more data.

My position has always been that, as I/O streams, we need to supply both. However, in https://github.com/yutakahirano/fetch-with-streams/issues/30 it was argued that (1) is not useful for HTTP streams, since acceptance by the kernel is not actionable information. There was some subsequent discussion wondering whether this is generally true; a counterexample given was a writable stream representing a database where each write represents a commit to the database.

I'm not sure what to think yet, but want to log this issue.

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