display SSL variables for ?auto output

mod_status ?auto output wasn't implemented for SSL cache. Start by
implementing output for SHMCB, which is what we use.
don't waste ... time. calling times()

times() -> thread_group_times -> thread_group_cputime -> iterate over every
thread in the process group.

"times()" was called on every request in every thread.
Make sure BEAST mitigation is not disabled
Add SSLSendEmptyFragments option

This is to make the BEAST mitigation optional
reuseport support. requires apr bump
ssl session ticket timeout

hardcode to 4 hours for now. have to add a new "module configuration setting"
or figure out how to set the ticket session timeout from the vhost context.

the callback for setting up a ticket doesn't seem to have access to the
session or the ctx or anywhere I can find to specify the session timeout.
crank a few socache_memcache values

I think these defaults were due to an old bug in APR, wherein persistent
connections bloated memory forever. I see that the patch was applied years
ago, so lets try upping it.

default timeout for closing an existing memcache conn was 600 *microseconds*.
FFS.
debugging Listen problem
Retry on ephemeral fcntl EDEADLK

fcntl isn't thread aware, so it thinks that fcntl locks in unrelated threads
have a locking order dependency problem and bail out. We can just keep
retrying in a loop here.

(not 100% confident that is the explanation, but it's likely since this only
happens if you have multiple fcntl locks going on)
backport r1526168, r1527291, r1527294, r1527295 and r1527926 from trunk

Submitted by: kbrand
Reviewed by:

Streamline and improve ephemeral key handling:

- drop support for ephemeral RSA keys (only allowed/needed
  for export ciphers)

- drop pTmpKeys from the per-process SSLModConfigRec, and remove
  the temp key generation at startup (unnecessary for DHE/ECDHE)

- unconditionally disable null and export-grade ciphers by always
  prepending "!aNULL:!eNULL:!EXP:" to any cipher suite string

- do not configure per-connection SSL_tmp_*_callbacks, as it is
  sufficient to set them for the SSL_CTX

- set default curve for ECDHE at startup, obviating the need
  for a per-handshake callback, for the time being (and also
  configure SSL_OP_SINGLE_ECDH_USE, previously left out)

- increase minimum required OpenSSL version to 0.9.8a, as we
  now rely on the get_rfcX_prime_Y functions from <openssl/bn.h>

- in ssl_private.h, regroup definitions based on whether
  they depend on TLS extension support or not

- for ECC and SRP support, set HAVE_X and change the rather awkward
  #ifndef OPENSSL_NO_X lines accordingly

- allow to configure custom DHE or ECDHE parameters via the
  SSLCertificateFile directive, and adapt its documentation
  accordingly (addresses PR 49559)

- add standardized DH parameters from RFCs 2409 and 3526,
  use them based on the length of the certificate's RSA/DSA key,
  and add a FAQ entry for clients which limit DH support
  to 1024 bits (such as Java 7 and earlier)

- move ssl_dh_GetParamFromFile() from ssl_engine_dh.c to
  ssl_util_ssl.c, and add ssl_ec_GetParamFromFile()

- drop ssl_engine_dh.c from mod_ssl
reuse listening sockets if address and port match

An unintended side-effect of the upstream change r100999 was that
one Listen command would reuse *all* the existing listeners that had
a matching address and port.

That behavior clashed with our use of multiple identical listeners.
The first Listen command in the configuration one would reuse all
existing listeners.  The other Listen commands would then create
additional listeners, leading to more and more listeners after every
graceful restart.

Commit d94449e7 earlier on this branch disabled the listener
reuse logic in order to work around this proliferation problem.

This commit fixes the listener reuse logic, so that each Listen
command reuses at most one matching listener from the old list.

In consequence, no listeners will be closed or created during a graceful
restart if the new listener configuration matches the current configuration.

In turn this fixes the problem that connections in the listen queue
were getting closed during a graceful restart.
stagger the graceful exit of child processes, conf GracefulExitDelay

With the configuration command GracefulExitDelay set to a short time
such as "100ms", child processes managed by the worker MPM will exit
in a staggered way when they receive the shutdown message through the
Pipe Of Death.

In consequence, during a graceful restart, child processes remain
available for handling incoming requests.  Without this change,
there is a window of time during which requests are queued but
not handled, which delays those requests by several seconds.

On the other side, this introduces a delay in the graceful restart
process.  With "GracefulExitDelay 100ms" and "ServerLimit 32"
a graceful restart will take at least 3.2 seconds.
Merge pull request #1 from fastly/jozef/graceful

graceful restart: reuse listening sockets, stagger child process restarts
Re-use the accept mutex on a graceful restart

Previously the clean-up of the pconf pool during a graceful
restart in the main process would destroy the mutex.  For the
sysv and pthread mutex types, the fact that the parent process
destroyed the mutex caused operations on it in the child process
to fail immediately, defeating the purpose of GracefulExitDelay.
This was not a problem for the fcntl mutex type (because the
destroy function merely closes the underlying file), but the
fcntl mutex type has been found to be spinlock-heavy.

With this commit the accept mutex is tied to the global pool
instead of the pconf pool and worker_run reuses the mutex
after it has been created once.

As a consequence of that, to change the accept mutex type
a full restart is needed.
Option to not remove non-standard header fields from 304 responses

Filter304Headers On : [default] current behavior, only keep
                      the following header fields in a 304 response:
                        * Connection
                        * Keep-Alive
                        * ETag
                        * Content-Location
                        * Expires
                        * Cache-Control
                        * Vary
                        * Warning
                        * WWW-Authenticate
                        * Proxy-Authenticate
                        * Set-Cookie
                        * Set-Cookie2

Filter304Headers Off: treat 304 no different from other responses
                      and pass all header fields through
Merge pull request #2 from fastly/jozef/reuse-accept-mutex

Re-use the accept mutex on a graceful restart
Merge pull request #3 from fastly/jozef/do-not-filter-304-headers

Option to not remove non-standard header fields from 304 responses
If we don't get an HTTP response back, it's a protocol error

I assure you it is not a proxy speaking a protocol that was only ever
formalized by the introduction of a standardized protocol that superceded
it.