Previously, bidirectional shutdown never worked, due to two issues
in the code:

1. The code only tested SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE
   when there was an error in the error queue, which cannot happen.
   The bug was introduced in an attempt to fix unexpected error logging
   as reported with OpenSSL 0.9.8g
   (http://mailman.nginx.org/pipermail/nginx/2008-January/003084.html).

2. The code never called SSL_shutdown() for the second time to wait for
   the peer's close_notify alert.

This change fixes both issues.

Note that after this change bidirectional shutdown is expected to work for
the first time, so c->ssl->no_wait_shutdown now makes a difference.  This
is not a problem for HTTP code which always uses c->ssl->no_wait_shutdown,
but might be a problem for stream and mail code, as well as 3rd party
modules.

To minimize the effect of the change, the timeout, which was used to be 30
seconds and not configurable, though never actually used, is now set to
3 seconds.  It is also expanded to apply to both SSL_ERROR_WANT_READ and
SSL_ERROR_WANT_WRITE, so timeout is properly set if writing to the socket
buffer is not possible.

Previous behaviour was to pass everything to the client, but this
seems to be suboptimal and causes issues (ticket #1695).  Fix is to
drop extra data instead, as it naturally happens in most clients.

This change covers generic buffered and unbuffered filters as used
in the scgi and uwsgi modules.  Appropriate input filter init
handlers are provided by the scgi and uwsgi modules to set corresponding
lengths.

Note that for responses to HEAD requests there is an exception:
we do allow any response length.  This is because responses to HEAD
requests might be actual full responses, and it is up to nginx
to remove the response body.  If caching is enabled, only full
responses matching the Content-Length header will be cached
(see b779728b180c).

Using SSL_CTX_set_verify(SSL_VERIFY_PEER) implies that OpenSSL will
send a certificate request during an SSL handshake, leading to unexpected
certificate requests from browsers as long as there are any client
certificates installed.  Given that ngx_ssl_trusted_certificate()
is called unconditionally by the ngx_http_ssl_module, this affected
all HTTPS servers.  Broken by 699f6e55bbb4 (not released yet).

Fix is to set verify callback in the ngx_ssl_trusted_certificate() function
without changing the verify mode.

When validating second and further certificates, ssl callback could be called
twice to report the error.  After the first call client connection is
terminated and its memory is released.  Prior to the second call and in it
released connection memory is accessed.

Errors triggering this behavior:
- failure to create the request
- failure to start resolving OCSP responder name
- failure to start connecting to the OCSP responder

The fix is to rearrange the code to eliminate the second call.

This ensures that certificate verification is properly logged to debug
log during upstream server certificate verification.  This should help
with debugging various certificate issues.

When enabled, certificate status is stored in cache and is used to validate
the certificate in future requests.

New directive ssl_ocsp_cache is added to configure the cache.

OCSP validation for client certificates is enabled by the "ssl_ocsp" directive.
OCSP responder can be optionally specified by "ssl_ocsp_responder".

When session is reused, peer chain is not available for validation.
If the verified chain contains certificates from the peer chain not available
at the server, validation will fail.

Previously only the first responder address was used per each stapling update.
Now, in case of a network or parsing error, next address is used.

This also fixes the issue with unsupported responder address families
(ticket #1330).