Clients sending too many RST_STREAM is an irregular behavior.
Hack in a preceding END_STREAM DATA frame padded towards [48, 72]
before RST_STREAM so that the TLS record looks like a HEADERS frame.
The server often replies to this with a WINDOW_UPDATE because padding
is accounted in flow control. Whether this constitudes a new irregular
behavior is still unclear.
Client: On the first connection does a full Open and detects if the
server supports padding by checking for "Padding" header in the
response. Applies padding if the server does. In the following
connections it's back to Fast Open.
Server: Detects if the client supports padding by checking for "Padding"
header in the CONNECT request. Applies padding if the client does.
Both client and server always send "Padding" headers to somewhat protect
the request and response headers' packet lengths, even if the other side
may not acknowledge padding negotiation, either due to old version or
"Padding" headers being dropped by the frontend.
The manual option --padding is removed.
In HttpProxySocket there can be data immediately after HTTP headers,
as in the case of fast HTTP CONNECT.
Instead of reporting an error, handle this case by returning
the data after HTTP headers in the next Read() call.
SpdyProxyClientSocket uses read_callback_ for both Connect() and
Read(), and its OnIOComplete() calls read_callback_, thus its fast
connect code checks read_callback_. The code was ported to
QuicProxyClientSocket without much change.
But QuicProxyClientSocket uses a separate connect_callback_ apart from
read_callback_, and its OnIOComplete() calls connect_callback_, thus
when headers are received after Connect() it doesn't need to check
read_callback_ and should always avoid calling connect_callback_.
