This gives us an accurate view of the configuration before running
the update, and the correct current configuration version.

For more robust e2e tests.

For more robust e2e tests.

Cached responses from other tests had been interfering with the test.

Unfortunately, we got out of sync, so I will need to push uplex/master

XXX: currently does not always delete haproxy backends for onload
when it should. This can be demonstrated with the tls/onload test:
deploy, verify, undeploy, then deploy again. The second deployment
fails because the haproxy backend from the first run, which should
have been removed by undeployment, still exists and is reported
by dataplane as 409 Conflict.

Adjust gitlab ci

See merge request uplex/varnish/k8s-ingress!17

chore: apply lint rules to ingress.go

See merge request uplex/varnish/k8s-ingress!15

Both are now obtained from the repo at pkg.uplex.de, and differ only
in:
- the version, dist and pool parameters of the source repo, as
  expressed in /etc/apt/sources.list, and
- the list of VMODs to install.

We now have one Dockerfile for the two containers, and the four
parameters listed above are passed into the build as build-args,
using values set in the Makefile.

This also has the effect of changing the base image for klarlack
to Debian slim, updated to the currently most recent version.

The Dockerfile is now simpler than the previous version for
klarlack, in that we set the version once in the repo path, rather
than specify "=${VERSION}" for Varnish and each VMOD in the
apt install invocation.

This almost always happens because the API server's current version
of the Ingress has a newer ResourceVersion than the controller's
cached copy. Sometimes it happens during e2e tests when the Ingress
has already been deleted but the worker queue has not caught up.

Make one attempt to fetch a fresh copy of the Ingress from the API
server, and if necessary, update the LoadBalancer field for the
fresh version.

Inspired by the nginx ingress' solution to this problem.