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

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.

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.

$ vikingctrl --help
[...]
  -maxSyncRetries uint
    	maximum number of retires for cluster synchronizations
    	that fail due to recoverable errors, or because
    	necessary information is missing. 0 for unlimited
    	retries (default 0)
[...]

IOW set a maximum number of re-queues for SyncIncomplete and
SyncRecoverable type failures. By default unlimited.

While here, update some missing function parameter docs.

This reverts commit a42ae714.

kind could not be started in gitlab CI.

This sets the k8s version for both server and client to 1.29.1.

That is, when the addresses are not stored in the controller's
internal data structures.

Non-timeout network errors are not fatal when an instance is deleted,
for the same reasons given for removing a haproxy instance in the
prior commit.

It is also not fatal if the admin Secret is missing when we remove
a varnish instance, or when setting its config to the NotReady VCL.
Similar to reasons given for haproxy in prior commits -- in such
cases we assume that Secret has been deleted in an undeployment
operation, so its not necessary to set a "not configured" state,
since the instance will be removed imminently.

While here, make sure that dataplane transactions get deleted,
including after errors.

We assume that haproxy has been stopped (and the Pod may have been
deleted).

Go's "permanent network error" is now deprecated, so we limit this
distinction to timeout errors.

We assume that the Service is being deleted, and delete Secret has
already been executed; then it is not necessary to re-configure
the offloader, since it wil be deleted altogether.

Delay for a bit after deployment, to make sure that haproxy
re-configuration/restart is complete before verifying the test.

The test needs haproxy on the path, otherwise it's skipped.

That is, if the varnish controller has stored no instances in its
own data structures.

We try to set the admin Secret prior to the update operation, but
Incomplete or Recoverable errors setting the Secret may be resolved
by the full update. So only fail the update on Fatal errors.

Encapsulate setting the admin Secret for a viking Service in a
common function.