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>

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.

If of.err is 0, it means that there was a memory allocation error
and no further logging and/or processing is needed.  The of.failed
string can be only accessed if of.err is not 0.

The ev->timedout flag is set on first timer expiration, and never reset
after it.  Due to this the code to stop the timer when the timer was
canceled never worked (except in a very specific time frame immediately
after start), and the timer was always armed again.  This essentially
resulted in a buffer flush at the end of an event loop iteration.

This behaviour actually seems to be better than just stopping the flush
timer for the whole shutdown, so it is preserved as is instead of fixing
the code to actually remove the timer.  It will be further improved by
upcoming changes to preserve cancelable timers if there are other timers
blocking shutdown.