For that, the Secret must be named as the TLS Secret by an Ingress
in the same namespace that identifies out ingress.class.

This means that the controller doesn't need to try delete an element
from any PEM Secret (to remove the certificate from the haproxy
Secret volume).

For the Unix domain socket over which haproxy and varnish communicate,
we have chmod 660 and chgrp varnish. haproxy belongs to group varnish
and thus has write permissions on the socket, which is required in
Linux to be able to connect.

For that, both containers must have the same group name and GID.
We've been using 998, since that results from the RPM install for
Varnish from the official packagecloud repos.

Mention the haproxy container, and the Helm charts folder.

For the most part by adding go docs, and by using Go naming
conventions in a few cases.

Remove some commented-out code while we're here.

Quiets golint.

Use the label key viking.uplex.de/secret. The controller only reads
Secrets with this label, and with the field type:kubernetes.io/tls
(the latter are Secrets specified for Ingress).

Three values are permitted for the label:

admin: credentials for remote admin of Varnish and haproxy (Varnish
shared secret and Basic Auth password for the dataplane API).

pem: initially empty Secret into which the controller writes pem
files (concatenated crt and key), projected into a volume from
which haproxy reads at load time. Currently only with the hard-
wired name "tls-cert", so that RBAC update privileges can be
limited to this Secret.

auth: credentials for Basic and Proxy Auth, as configured via
the VarnishConfig custom resource.

We read Secrets with labels that identify a Secret for use by this
application. These include:

- Secrets for the remote administration of Varnish and haproxy
  (to authorize use of the Varnish CLI and the dataplane API for
  haproxy).

- Secrets for applications like Basic and Proxy Auth.

- The Secret in which PEM files for haproxy are created, and
  is projected into a volume that haproxy reads. This is how we
  create TLS material for use by haproxy (which requires that
  crt and key are concatenated into one file).

We also read Secrets with the type field set to "kubernetes.io/tls".
These contain the TLS material, and are the Secrets named in an
Ingress spec.

This has necessitated adding two new informers to the controller,
for which the filters are defined.