Removed useless parameter arm_version=0 in aarch64 builds.
Re-added arm_arm1176jzf-s_vfp, arm_arm926ej-s, arm_mpcore, arm_xscale
due to previously missing arm_use_thumb=false in build.
Re-added arm_cortex-a5_vfpv4, missing in 19.07.8 but back in 21.02.0.
Added arm_cortex-a7 (mediatek/mt7629), new in 21.02.0.
Removed arm_cortex-a8_neon (samsung/s5pv210), removed in 21.02.0.
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.
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_.
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.
