RTCQuicStreamState: Definitions and implications for Readable and Writeable

[aboba]

We have combined the half-closed-remote and half-closed-local states from the QUIC transport document into a single "closing" state. Also, we have both finish and reset methods. Some questions:

1. Does receipt of a STREAM frame with the FIN bit set automatically cause the RTCQuicStream object to send a STREAM frame with the FIN bit set in reply? Or does this not happen until the local peer calls finish()?

2. Does receipt of a STREAM frame with the FIN bit set affect either the Readable or Writeable slots on the local peer?

3. Does receipt of a RST_STREAM frame automatically cause the RTCQuicStream object to send a RST_STREAM frame in reply?

4. Does receipt of a RST_STREAM frame cause both the Readable and Writeable slots on the local peer to be set to false?

5. Calling reset() causes both the Readable and Writeable slots to transition to false, correct?

6. Calling finish() causes the Writeable slot to transition to false, but does not affect the Readable slot on the local peer, correct?

[aboba]

Preliminary answer to the above questions:

1. Have to call finish() to cause a STREAM frame with the Fin bit set to be sent, RTCQuicStream won't do this automatically.

2. Receipt of STREAM frame with the Fin bit set does not affect Writeable slot (have to call finish locally for that to be set to false) or immediately affect the Readable slot (have to call readInto to encounter the EOF, after which Readable is set to false).

3. RST_STREAM frames are automatically sent in response to receiving a RST_STREAM frame (which causes the protocol state to transition to "closed").

4. Yes.

5. Yes.

6. Yes.

[aboba]

@robin-raymond @pthatcher Thoughts?