If the flag space_in_uri is set, the URI in HTTP upstream request is escaped to
convert space to %20.  However this flag is not checked while creating the
default cache key.  This leads to different cache keys for requests
'/foo bar' and '/foo%20bar', while the upstream requests are identical.

Additionally, the change fixes background cache updates when the client URI
contains unescaped space.  Default cache key in a subrequest is always based on
escaped URI, while the main request may not escape it.  As a result, background
cache update subrequest may update a different cache entry.

Previously, the unparsed uri was explicitly allowed to be used only by the main
request.  However the valid_unparsed_uri flag is nonzero only in the main
request, which makes the main request check pointless.

If a connection with the read delayed flag set was stored in the keepalive
cache, and after picking it from the cache a read timer was set on that
connection, this timer was considered a delay timer rather than a socket read
event timer as expected.  The latter timeout is usually much longer than the
former, which caused a significant delay in request processing.

The issue manifested itself with proxy_limit_rate and upstream keepalive
enabled and exists since 973ee2276300 (1.7.7) when proxy_limit_rate was
introduced.

A zlib variant from Intel as available from https://github.com/jtkukunas/zlib
uses 64K hash instead of scaling it from the specified memory level, and
also uses 16-byte padding in one of the window-sized memory buffers, and can
force window bits to 13 if compression level is set to 1 and appropriate
compile options are used.  As a result, nginx complained with "gzip filter
failed to use preallocated memory" alerts.

This change improves deflate_state allocation detection by testing that
items is 1 (deflate_state is the only allocation where items is 1).
Additionally, on first failure to use preallocated memory we now assume
that we are working with the Intel's modified zlib, and switch to using
appropriate preallocations.  If this does not help, we complain with the
usual alerts.

Previous version of this patch was published at
http://mailman.nginx.org/pipermail/nginx/2014-July/044568.html.
The zlib variant in question is used by default in ClearLinux from Intel,
see http://mailman.nginx.org/pipermail/nginx-ru/2017-October/060421.html,
http://mailman.nginx.org/pipermail/nginx-ru/2017-November/060544.html.

If parameters were specified in xslt_stylesheet without variables,
any request except the first would cause an internal server error.

Previously, nginx failed to move buffer position when parsing an incomplete
record header, and due to this wasn't be able to continue parsing once
remaining bytes of the record header were received.

This can affect response header parsing, potentially generating spurious errors
like "upstream sent unexpected FastCGI request id high byte: 1 while reading
response header from upstream".  While this is very unlikely, since usually
record headers are written in a single buffer, this still can happen in real
life, for example, if a record header will be split across two TCP packets
and the second packet will be delayed.

This does not affect non-buffered response body proxying, due to "buf->pos =
buf->last;" at the start of the ngx_http_fastcgi_non_buffered_filter()
function.  Also this does not affect buffered response body proxying, as
each input buffer is only passed to the filter once.

This slightly reduces cost of selecting a peer if all or almost all peers
failed, see ticket #1030.  There should be no measureable difference with
other workloads.

While this may result in non-ideal distribution of requests if nginx
won't be able to select a server in a reasonable number of attempts,
this still looks better than severe performance degradation observed
if there is no limit and there are many points configured (ticket #1030).
This is also in line with what we do for other hash balancing methods.