The field is still optional, but if no default key is specified, then
it is implicitly the empty string. We no longer support a use case
in which an error response is returned for sharding by key if the
key is missing from the request. This will also be the case when
we support sharding by other keys besides cookies, such as request
headers.

This makes it possible to move the clause in vcl_recv that includes
the synthetic response to health checks from other shard instances
to come after the code for primaryOnly. That had been moved to the
start of vcl_recv, because health checks were failing in the shard
by cookie case without a default key (since health probes have no
Cookie header). But the result was that primaryOnly code did not
work as expected. Now we have moved that clause back to where it
was previously -- health probes now don't fail in the shard by
cookie case, because there is always a default key.

XXX: currently only used for sharding by cookie. Will be extended
for use with all by=KEY cases.

To ensure that health checks from other Varnish instances succeed
in the self-sharding configuration, move the clause in vcl_recv
that is executed when remote.ip matches the ACL for cluster members
to the start of the subroutine.

XXX: currently returns a synthetic 400 response if the configured
cookie name is not found in the Cookie header (or if there is no
Cookie header). In a further iteration, we will add an optional
field defaultKey, which if present sets a string value to be used
as the sharding key if the key is not found.

XXX: testing this feature has revealed bugs in sharding by key
(using by=KEY) unless primaryOnly is also set to true. These will
be fixed in a further iteration.

Fixing the dataplaneapi has resolved this problem. In the process of
debugging, a logger was added to the dataplaneapi client code, which
will now be retained.

The ARG that sets the version string in the Dockerfile must evidently
be set *after* the FROM statement, so that git checkout is invoked
correctly.

git checkout with the Dockerfile ARG for the version tag apparently
wasn't working, so the latest version was checked out and built.
That version currently doesn't work in the haproxy container, so
the container did not come up.

XXX: validation of the dataplane response to the /sites request is
currently commented out. This is causing a problem with testing
and will be investigated further.

And update VMOD versions as necessary.

We will add an option to the BackendConfig CRD to use them if desired.

Purely cosmetic, but now it really sounds like a viking controller.

The haproxy version remains the same, but it's no longer necessary
to install from a backports repo.

The Pods were not always fully deleted when the next test began
in the longer e2e test script, which interfered with execution.

Now using the SUB feature of VMOD re2. This simplifies and
improves the scalability of the matching logic (one subroutine
call, rather than an if-elsif sequence that is as long as the
number of paths). Will also simplify the implementation of
pathType for k8s-1.22.

This is due at any rate, and in particular the more recent versions
of VMOD re2 and selector support the VCL_SUB feature.