Reject http2 max-headers-list-size exceeded without ending connection

[jfallows]

When max-headers-list-size setting is exceeded by an http2 client, we currently end the connection to avoid potential HPACK context inconsistencies, but we should instead reject the new stream and let the connection proceed for other streams.

Leaving the connection intact requires that the HPACK state be maintained properly, even when a combination of HEADERS and CONTINUATION frames causes the max-headers-list-size setting to become exceeded.

First, we need to change the HEADERS and CONTINUATION decode logic to buffer the aggregated output of the decoded headers, not the aggregated input. This allows accurate enforcement of max-headers-list-size which is described in terms of decoded header list size.

Note: the encoded form of an individual header may still span across HTTP/2 frames, so a partial encoded header may need to be buffered for later decode, in addition to the already decoded output of previous headers.

Then, when max-headers-list-size is exceeded, we need to continue to update the HPACK context for the connection by processing all the received headers, even though they will be discarded. In some cases these discarded headers will become entries in the HPACK dynamic table for use by future requests on the same connection.

Note: there is no need to buffer an individual header that exceeds the header-table-size setting because it cannot be stored in the HPACK dynamic table anyway.