This is in anticipation of removing the rule that a viking service
implements an Ingress if it's the only one in the entire cluster.
This can cause unexpected changes if something unrelated in the
cluster is changed, for example by independent teams working in
different namespaces.

This makes it unnecessary to undeploy the viking service that always
runs in namespace default during e2e tests (which was just such a
dependency).

The docs are not currently up to date on this point.

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.