In ngx_http_range_singlepart_body() special buffers where passed
unmodified, including ones after the end of the range.  As such,
if the last buffer of a response was sent separately as a special
buffer, two buffers with b->last_buf set were present in the response.

In particular, this might result in a duplicate final chunk when using
chunked transfer encoding (normally range filter and chunked transfer
encoding are not used together, but this may happen if there are trailers
in the response).  This also likely to cause problems in HTTP/2.

Fix is to skip all special buffers after we've sent the last part of
the range requested.  These special buffers are not meaningful anyway,
since we set b->last_buf in the buffer with the last part of the range,
and everything is expected to be flushed due to it.

Additionally, ngx_http_next_body_filter() is now called even
if no buffers are to be passed to it.  This ensures that various
write events are properly propagated through the filter chain.  In
particular, this fixes test failures observed with the above change
and aio enabled.

Filters are not allowed to change incoming chain links, and should allocate
their own links if any modifications are needed.  Nevertheless
ngx_http_range_singlepart_body() modified incoming chain links in some
cases, notably at the end of the requested range.

No problems caused by this are currently known, mostly because of
limited number of possible modifications and the position of the range
body filter in the filter chain.  Though this behaviour is clearly incorrect
and tests demonstrate that it can at least cause some proxy buffers being
lost when using proxy_force_ranges, leading to less effective handling
of responses.

Fix is to always allocate new chain links in ngx_http_range_singlepart_body().
Links are explicitly freed to ensure constant memory usage with long-lived
requests.

If ngx_pool_cleanup_add() fails, we have to clean just created SSL context
manually, thus appropriate call added.

Additionally, ngx_pool_cleanup_add() moved closer to ngx_ssl_create() in
the ngx_http_ssl_module, to make sure there are no leaks due to intermediate
code.

A virtual server may have no SSL context if it does not have certificates
defined, so we have to use config of the ngx_http_ssl_module from the
SSL context in the certificate callback.  To do so, it is now passed as
the argument of the callback.

The stream module doesn't really need any changes, but was modified as
well to match http code.

Dynamic certificates re-introduce problem with incorrect session
reuse (AKA "virtual host confusion", CVE-2014-3616), since there are
no server certificates to generate session id context from.

To prevent this, session id context is now generated from ssl_certificate
directives as specified in the configuration.  This approach prevents
incorrect session reuse in most cases, while still allowing sharing
sessions across multiple machines with ssl_session_ticket_key set as
long as configurations are identical.

Passwords have to be copied to the configuration pool to be used
at runtime.  Also, to prevent blocking on stdin (with "daemon off;")
an empty password list is provided.

To make things simpler, password handling was modified to allow
an empty array (with 0 elements and elts set to NULL) as an equivalent
of an array with 1 empty password.

To evaluate variables, a request is created in the certificate callback,
and then freed.  To do this without side effects on the stub_status
counters and connection state, an additional function was introduced,
ngx_http_alloc_request().

Only works with OpenSSL 1.0.2+, since there is no SSL_CTX_set_cert_cb()
in older versions.

Previous interface of ngx_open_dir() assumed that passed directory name
has a room for NGX_DIR_MASK at the end (NGX_DIR_MASK_LEN bytes).  While all
direct users of ngx_dir_open() followed this interface, this also implied
similar requirements for indirect uses - in particular, via ngx_walk_tree().

Currently none of ngx_walk_tree() uses provides appropriate space, and
fixing this does not look like a right way to go.  Instead, ngx_dir_open()
interface was changed to not require any additional space and use
appropriate allocations instead.

Previously, AF_UNIX addresses misbehaved as AF_INET, which typically resulted
in $uid_set composed from the middle of sun_path.