commit 3c4eabf739f52c0839b00445203aa7c39167d09d
author fkastenholz <fkastenholz@google.com> Mon Apr 22 07:49:59 2019 -0700
committer Copybara-Service <copybara-worker@google.com> Mon Apr 22 08:42:15 2019 -0700
tree 0945bb78b2287e0397fbc5b2d99f41fb4916adba
parent 9f459cbe9aad63cb4e50a6b83c48b7c96e7365e1

Add QuicStreamsBlockedFrame and QuicMaxStreamsFrame classes

There are two main parts to this work
1) connecting up the new frames, replacing the old ones, to move data around the
   system. This also entails a lot of editorial changes (just changing names, comments,
   and so on, without notable logic chanages -- eg, "OnMaxStreamIdFrame" becomes
   "OnMaxStreamsFrame".

2) the second, and more complex, task is revising the stream id manager to work entirely
   with stream counts rather than stream-ids. For example, the logic to check whether a
   new stream can be created checks if the current-stream-count is less than the limit
   or not, rather than if the next stream id to hand out is above the limit or not.
   For all intents and purposes, this completely rewrote the stream ID manager.

   Another big change resulting from keeping track solely of stream counts is that the
   stream ID manager doesn't care whether it is doing unidirectional or bidirectional
   streams, nor does it care whether stream ids are client- or server- initiated.

gfe-relnote: N/A, all changes are for V99/IETF QUIC code only.

LOG_STORAGE_INCREASE(GB/week): 0
TMPLOG_STORAGE_INCREASE(GB): 0

This change neither adds nor deletes data stored. It adds two new codepoints to the QUIC FrameType enum.  These new enums reflect two new frames defined in IETF QUIC, which replace two now-deprecated frames (and their associated type codepoints). This is a name change/type codepoint extension; data is neither added nor deleted.

PiperOrigin-RevId: 244661277
Change-Id: I07cdb79db6bd15e1d5ece97b3aa2d67e94ccf00b