These are internal values of the Varnish/klarlack container, which
can be set differently with environment variables. Probably in nearly
all deployments, they will be left with the defaults.

- http target port (Varnish listener address)
- varnishadm port
- config check port
- readiness check port
- admin secret directory and file name

Make them independent on the order of execution, and do not depend
on deleting and finally re-installing the viking Pods in namespace
default that otherwise run throughout the e2e tests.

If the controller is watching resources in all namespaces (CLI option namespace
is not set, helm value vikingController.namespace is undefined or empty), then
define a ClusterRole as we do now.

In the helm chart we use the prefix "viking.uplex.de:" in the ClusterRole's
name, since ClusterRoles are not namespaced.

If the controller is watching one namespace (CLI option namespace, helm value
vikingController.namespace are set to the namespace), define a Role in the
namespace, and a RoleBinding to connect it to the ServiceAccount. Then the
restriction to the namespace is enforced by RBAC.

For the viking service (Varnish/haproxy-as-Ingress implementation): in place
of the ClusterRole and ClusterRoleBinding we have now, define a Role and
RoleBinding in the namespace in which the Pods run. This enforces the
restriction to the namespace. RBAC is needed to read TLS Secrets, which must
be in the same namespace.

This means that the k8s-crt-dnldr running in the haproxy container must be
invoked with the namespace CLI arg. For that, we use the downward API to
pass POD_NAMESPACE into the container.

The namespace example is adjusted for these changes, and a Makefile drives
the tests, using both helm and kubectl.

The archtiectures and varnish_pod_template tests have also been adjusted,
although for now these are run only with kubectl.

Invoke with:
$ PATH=$PATH:/dir/for/haproxy TEST=local DEPLOY=kubectl ./test/e2e.sh

The PATH to find haproxy allows tests that require it to run (otherwise
they are skipped).

We currently deploy with kubectl rather than helm due to naming
differences.

This made it necessary to separate the RBAC and ServiceAccount
maifests for controller and varnish.

We now have deploy and undeploy targets for both controller and
Varnish that use helm or kubectl, depending on whether the make
variable DEPLOY=kubectl is set.

make variable DEPLOY=kubectl specifies these variants for the targets
deploy- and undeploy-controller, otherwise un/deploy the helm chart.