OCSP response verification is now switched off by default to simplify
configuration, and the ssl_stapling_verify allows to switch it on.

Note that for stapling OCSP response verification isn't something required
as it will be done by a client anyway.  But doing verification on a server
allows to mitigate some attack vectors, most notably stop an attacker from
presenting some specially crafted data to all site clients.

This includes the ssl_stapling_responder directive (defaults to OCSP
responder set in certificate's AIA extension).

OCSP response for a given certificate is requested once we get at least
one connection with certificate_status extension in ClientHello, and
certificate status won't be sent in the connection in question.  This due
to limitations in the OpenSSL API (certificate status callback is blocking).

Note: SSL_CTX_use_certificate_chain_file() was reimplemented as it doesn't
allow to access the certificate loaded via SSL_CTX.

Very basic version without any OCSP responder query code, assuming valid
DER-encoded OCSP response is present in a ssl_stapling_file configured.

Such file might be produced with openssl like this:

openssl ocsp -issuer root.crt -cert domain.crt -respout domain.staple \
             -url http://ocsp.example.com

The directive allows to specify additional trusted Certificate Authority
certificates to be used during certificate verification.  In contrast to
ssl_client_certificate DNs of these cerificates aren't sent to a client
during handshake.

Trusted certificates are loaded regardless of the fact whether client
certificates verification is enabled as the same certificates will be
used for OCSP stapling, during construction of an OCSP request and for
verification of an OCSP response.

The same applies to a CRL (which is now always loaded).

With "always" gzip static returns gzipped content in all cases, without
checking if client supports it.  It is useful if there are no uncompressed
files on disk anyway.

This directive allows to test desired flag as returned by memcached and
sets Content-Encoding to gzip if one found.

This is reimplementation of patch by Tomash Brechko as available on
http://openhack.ru/.  It should be a bit more correct though (at least
I think so).  In particular, it doesn't try to detect if we are able to
gunzip data, but instead just sets correct Content-Encoding.

Noted by Gabor Lekeny.