Connection level flow control (CLFC) accounting on receipt of FIN/RST

Connection level flow control (CLFC) accounting on receipt of FIN/RST
for already closed streams.

This implements the following behavior discussed internally.

  Proposal: implement rch/jar's solution from earlier in the thread, in
  which "bytes sent" is added to the RST frame, and each endpoint must
  send a FIN or RST containing "bytes sent" on stream termination.

  This gets the job done pretty simply, and will make our flow control
  very similar to SPDY. We can investigate more exotic dynamic stream
  window scaling (as per avd's suggestion earlier in the thread) in
  future if SPDY-style flow control is shown to be a problem.

A stream *must* send either a FIN or a RST on termination, either of
which contain enough data that the peer can definitively determine how
many bytes were sent on that stream (this is already implemented). This
CL implements the correct CLFC accounting of these frames when received
after the stream has been closed locally.

Motivating example: Client sends GET+FIN, Server sends response. Before
response arrives, client RSTs the stream (user closed tab?), tearing
down local state. Before this CL, when the server response arrives it
just gets dropped - but the server has counted the bytes sent against
its CLFC _send_ window. The client will not count these bytes against
it's CLFC _receive_ window, and so the endpoint states are now out of
sync.

To fix this, when a stream is closed we store the current "last bytes
received offset" in a map in the session, and handle a FIN/RST for a
closed stream by removing the difference between the final byte offset
from FIN/RST and the stored value from the map to the CLFC receive
window.

QUIC: Connection level flow control accounting on receipt of FIN/RST for
already closed streams. Protected behind existing flag:
FLAGS_enable_quic_connection_flow_control

Merge internal change: 68555475

R=rch@chromium.org, rjshade@google.com

[Robbie Shade, 2014-06-09 21:12:28]

lgtm