This change adds "http_429" parameter to "proxy_next_upstream" for
retrying rate-limited requests, and to "proxy_cache_use_stale" for
serving stale cached responses after being rate-limited.

Signed-off-by: Piotr Sikora <piotrsikora@google.com>

This change adds reason phrase in status line and pretty response body
when "429" status code is used in "return", "limit_conn_status" and/or
"limit_req_status" directives.

Signed-off-by: Piotr Sikora <piotrsikora@google.com>

When a slice subrequest was redirected to a new location, its context was lost.
After its completion, a new slice subrequest for the same slice was created.
This could lead to infinite loop.  Now the slice module makes sure each slice
subrequest starts output with the slice context available.

Previously, if slice main request write handler was called while a slice
subrequest was running, a new subrequest for the same slice was started.

With post_action or subrequests, it is possible that the timer set for
wev->delayed will expire while the active subrequest write event handler
is not ready to handle this.  This results in request hangs as observed
with limit_rate / sendfile_max_chunk and post_action (ticket #776) or
subrequests (ticket #1228).

Moving the handling to the connection event handler fixes the hangs observed,
and also slightly simplifies the code.

Much like in limit_req, use the wev->delayed flag to ensure proper handling
and interoperability with limit_rate.

Since limit_req uses connection's write event to delay request processing,
it can conflict with timers in other subrequests.  In particular, even
if applied to an active subrequest, it can break things if wev->delayed
is already set (due to limit_rate or sendfile_max_chunk), since after
limit_req finishes the wev->delayed flag will be set and no timer will be
active.

Fix is to use the wev->delayed flag in limit_req as well.  This ensures that
wev->delayed won't be set after limit_req finishes, and also ensures that
limit_req's timers will be properly handled by other subrequests if the one
delayed by limit_req is not active.

Signed-off-by: Piotr Sikora <piotrsikora@google.com>

All streams in connection must be finalized before the connection
itself can be finalized and all related memory is freed.  That's
not always possible on the current event loop iteration.

Thus when the last stream is finalized, it sets the special read
event handler ngx_http_v2_handle_connection_handler() and posts
the event.

Previously, this handler didn't check the connection state and
could call the regular event handler on a connection that was
already in finalization stage.  In the worst case that could
lead to a segmentation fault, since some data structures aren't
supposed to be used during connection finalization.  Particularly,
the waiting queue can contain already freed streams, so the
WINDOW_UPDATE frame received by that moment could trigger
accessing to these freed streams.

Now, the connection error flag is explicitly checked in
ngx_http_v2_handle_connection_handler().