Previously, an unavailable peer was considered recovered after a successful
proxy session to this peer.  Until then, only a single client connection per
fail_timeout was allowed to be proxied to the peer.

Since stream sessions can be long, it may take indefinite time for a peer to
recover, limiting the ability of the peer to receive new connections.

Now, a peer is considered recovered after a successful TCP connection is
established to it.  Balancers are notified of this event via the notify()
callback.

Unlimited recursion might cause stack exhaustion in some misconfigurations.

New directives: "ssl_verify_client", "ssl_verify_depth",
"ssl_client_certificate", "ssl_trusted_certificate", and
"ssl_crl".

New variables: $ssl_client_cert, $ssl_client_raw_cert,
$ssl_client_s_dn, $ssl_client_i_dn, $ssl_client_serial,
$ssl_client_fingerprint, $ssl_client_verify, $ssl_client_v_start,
$ssl_client_v_end, and $ssl_client_v_remain.

SSL version 3.0 can be specified by the client at the record level for
compatibility reasons.  Previously, ssl_preread module rejected such
connections, presuming they don't have SNI.  Now SSL 3.0 is allowed at
the record level.

By default, "map" creates cacheable variables [1].  With this
parameter it creates a non-cacheable variable.

An original idea was to deduce the cacheability of the "map"
variable by checking the cacheability of variables specified
in source and resulting values, but it turned to be too hard.
For example, a cacheable variable can be overridden with the
"set" directive or with the SSI "set" command.  Also, keeping
"map" variables cacheable by default is good for performance
reasons.  This required adding a new parameter.

[1] Before db699978a33f (1.11.0), the cacheability of the
"map" variable could vary depending on the cacheability of
variables specified in resulting values (ticket #1090).
This is believed to be a bug rather than a feature.

No functional changes.

The variable contains a list of curves as supported by the client.
Known curves are listed by their names, unknown ones are shown
in hex, e.g., "0x001d:prime256v1:secp521r1:secp384r1".

Note that OpenSSL uses session data for SSL_get1_curves(), and
it doesn't store full list of curves supported by the client when
serializing a session.  As a result $ssl_curves is only available
for new sessions (and will be empty for reused ones).

The variable is only meaningful when using OpenSSL 1.0.2 and above.
With older versions the variable is empty.

The variable contains list of ciphers as supported by the client.
Known ciphers are listed by their names, unknown ones are shown
in hex, e.g., ""AES128-SHA:AES256-SHA:0x00ff".

The variable is fully supported only when using OpenSSL 1.0.2 and above.
With older version there is an attempt to provide some information
using SSL_get_shared_ciphers().  It only lists known ciphers though.
Moreover, as OpenSSL uses session data for SSL_get_shared_ciphers(),
and it doesn't store relevant data when serializing a session.  As
a result $ssl_ciphers is only available for new sessions (and not
available for reused ones) when using OpenSSL older than 1.0.2.

If proxy_pass (and friends) with variables evaluates an upstream
specified with literal address, nginx always created a per-request
upstream.

Now, if there's a matching upstream specified in the configuration
(either implicit or explicit), it will be used instead.