This could happen when graceful shutdown configured by worker_shutdown_timeout
times out and is then followed by another timeout such as proxy_read_timeout.
In this case, the HEADERS frame is added to the output queue, but attempt to
send it fails (due to c->error forcibly set during graceful shutdown timeout).
This triggers request finalization which attempts to close the stream.  But the
stream cannot be closed because there is a frame in the output queue, and the
connection cannot be finalized.  This leaves the connection open without any
timer events leading to alert.

The fix is to post write event when sending output queue fails on c->error.
That will finalize the connection.

With this patch, all traffic over an HTTP/2 connection is counted in
the h2c->total_bytes field, and payload traffic is counted in
the h2c->payload_bytes field.  As long as total traffic is many times
larger than payload traffic, we consider this to be a flood.

In 8df664ebe037, we've switched to maximizing stream window instead
of sending RST_STREAM.  Since then handling of RST_STREAM with NO_ERROR
was fixed at least in Chrome, hence we switch back to using RST_STREAM.

This allows more effective rejecting of large bodies, and also minimizes
non-payload traffic to be accounted in the next patch.

Don't waste server resources by sending RST_STREAM frames.  Instead,
reject WINDOW_UPDATE frames with invalid zero increment by closing
connection with PROTOCOL_ERROR.

Don't waste server resources by sending RST_STREAM frames.  Instead,
reject HEADERS and PRIORITY frames with self-dependency by closing
connection with PROTOCOL_ERROR.

When ngx_http_discard_request_body() call was added to ngx_http_send_response(),
there were no return codes other than NGX_OK and NGX_HTTP_INTERNAL_SERVER_ERROR.
Now it can also return NGX_HTTP_BAD_REQUEST, but ngx_http_send_response() still
incorrectly transforms it to NGX_HTTP_INTERNAL_SERVER_ERROR.

The fix is to propagate ngx_http_discard_request_body() errors.

As defined in HTTP/1.1, body chunks have the following ABNF:

   chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF

where chunk-data is a sequence of chunk-size octets.

With this change, chunk-data that doesn't end up with CRLF at chunk-size
offset will be treated as invalid, such as in the example provided below:

4
SEE-THIS-AND-
4
THAT
0

Previously, if unbuffered request body reading wasn't finished before
the request was redirected to a different location using error_page
or X-Accel-Redirect, and the request body is read again, this could
lead to disastrous effects, such as a duplicate post_handler call or
"http request count is zero" alert followed by a segmentation fault.

This happened in the following configuration (ticket #1819):

    location / {
        proxy_request_buffering off;
        proxy_pass http://bad;
        proxy_intercept_errors on;
        error_page 502 = /error;
    }

    location /error {
        proxy_pass http://backend;
    }