We take advantage of the fact that if a directory is specified for
haproxy as the location for certificates, then haproxy reads all
of the certificates found there, and automatically associates the
SNI of incoming connections with the appropriate certificate.

It contained a newline, which rendered the sed command in the entry
point of the haproxy container invalid.

The entrypoint of the haproxy container is an exec
script that sets the password from a template for
haproxy.cfg. Setting the password from an env
variable has proven to be too unreliable.

Also, listening at a UDS does not appear to be
working at all. So the dataplane API listens directly
at the container port (no intervening haproxy
frontend).

This change makes the container more friendly to
read-only filesystems, since haproxy.cfg is now no
longer modified in /etc, but rather in the ephemeral
file system at /run (== /var/run).

Most importantly, this tells us the current version number in use
by the dataplane API, which apparently insists that the number is
always counted up (otherwise there are 409 Conflict responses).

The Secret must be in the same namespace of the Pods into which
their contents are mounted.

The verification script intermittently gets a 503 status if requests
are sent to "soon", even after waiting for the Varnish Services to
become ready. It doesn't appear to happen if we wait a few seconds
longer.

For now, wait longer until we run the verification test case. In the
long run, we should investigate why the configuration is not actually
ready when the Ready state is reached.

Since the controller now interacts with the headless Service that
defines the admin ports, it can no longer find the http port in
that Service definition. This is needed to configure the Varnishen
as backends for one another.

Search for all Services in the same namespace that define the same
selector as the admin Service (and hence are configured for the
same Pods). We then search for the http port in the Endpoints of
those Services.