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 a complex value is expected to be of type size_t, and the compiled
value is constant, the constant size_t value is remembered at compile
time.

The value is accessed through ngx_http_complex_value_size() which
either returns the remembered constant or evaluates the expression
and parses it as size_t.

Previously only one address was used by the listen directive handler even if
host name resolved to multiple addresses.  Now a separate listening socket is
created for each address.

Server name callback is always called by OpenSSL, even
if server_name extension is not present in ClientHello.  As such,
checking c->ssl->handshaked before the SSL_get_servername() result
should help to more effectively prevent renegotiation in
OpenSSL 1.1.0 - 1.1.0g, where neither SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS
nor SSL_OP_NO_RENEGOTIATION is available.

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.

Notably this affects various allocation errors, and should generally
improve things if an allocation error actually happens during a callback.

Depending on the OpenSSL version, returning an error can result in
either SSL_R_CALLBACK_FAILED or SSL_R_CLIENTHELLO_TLSEXT error from
SSL_do_handshake(), so both errors were switched to the "info" level.

OpenSSL 1.1.1 does not save server name to the session if server name
callback returns anything but SSL_TLSEXT_ERR_OK, thus breaking
the $ssl_server_name variable in resumed sessions.

Since $ssl_server_name can be used even if we've selected the default
server and there are no other servers, it looks like the only viable
solution is to always return SSL_TLSEXT_ERR_OK regardless of the actual
result.

To fix things in the stream module as well, added a dummy server name
callback which always returns SSL_TLSEXT_ERR_OK.