Previously, there were only three timeouts used globally for the whole HTTP/2
connection:

 1. Idle timeout for inactivity when there are no streams in processing
    (the "http2_idle_timeout" directive);

 2. Receive timeout for incomplete frames when there are no streams in
    processing (the "http2_recv_timeout" directive);

 3. Send timeout when there are frames waiting in the output queue
    (the "send_timeout" directive on a server level).

Reaching one of these timeouts leads to HTTP/2 connection close.

This left a number of scenarios when a connection can get stuck without any
processing and timeouts:

 1. A client has sent the headers block partially so nginx starts processing
    a new stream but cannot continue without the rest of HEADERS and/or
    CONTINUATION frames;

 2. When nginx waits for the request body;

 3. All streams are stuck on exhausted connection or stream windows.

The first idea that was rejected was to detect when the whole connection
gets stuck because of these situations and set the global receive timeout.
The disadvantage of such approach would be inconsistent behaviour in some
typical use cases.  For example, if a user never replies to the browser's
question about where to save the downloaded file, the stream will be
eventually closed by a timeout.  On the other hand, this will not happen
if there's some activity in other concurrent streams.

Now almost all the request timeouts work like in HTTP/1.x connections, so
the "client_header_timeout", "client_body_timeout", and "send_timeout" are
respected.  These timeouts close the request.

The global timeouts work as before.

Previously, the c->write->delayed flag was abused to avoid setting timeouts on
stream events.  Now, the "active" and "ready" flags are manipulated instead to
control the processing of individual streams.

This is required for implementing per request timeouts.

Previously, the temporary pool was used only during skipping of
headers and the request pool was used otherwise.  That required
switching of pools if the request was closed while parsing.

It wasn't a problem since the request could be closed only after
the validation of the fully parsed header.  With the per request
timeouts, the request can be closed at any moment, and switching
of pools in the middle of parsing header name or value becomes a
problem.

To overcome this, the temporary pool is now always created and
used.  Special checks are added to keep it when either the stream
is being processed or until header block is fully parsed.

Without this the state might keep pointing to already closed stream.

Since 667aaf61a778 (1.1.17) the ngx_http_parse_header_line() function can return
NGX_HTTP_PARSE_INVALID_HEADER when a header contains NUL character.  In this
case the r->header_end pointer isn't properly initialized, but the log message
in ngx_http_process_request_headers() hasn't been adjusted.  It used the pointer
in size calculation, which might result in up to 2k buffer over-read.

Found with afl-fuzz.

The "always" parameter was ignored if the header value was empty.

Because of HPACK compression it's hard to see what headers are actually
sent by the server.

No functional changes.

When the "pending" value is zero, the "buf" will be right shifted
by the width of its type, which results in undefined behavior.

Found by Coverity (CID 1352150).

This reduces the size of headers by over 30% on average.

Based on the patch by Vlad Krasnov:
http://mailman.nginx.org/pipermail/nginx-devel/2015-December/007682.html