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.

This is necessary even if the controller is otherwise restricted to
a namespace. So we add a new ClusterRole to add the RBAC read rights
(wath, list and get) unconditionally for any controller instance.

Verified with the hello world example using kubectl/yaml deployment.

The other tests/examples, including all helm deployments, do not work
as of this commit, until they are adapted to the new logic for
configuring the Ingress class.

Its two fields are mapped directly to the ttl and ttl_from parameters
of VMOD dynamic.

We now work with Ingress from the API group networking.k8s.io. Ingress
in the extensions API group is no longer supported. This entails:

- update RBAC grants
- update client-go code
- update the examples/tests, currently only using helm deployments
  - changes in the Ingress backend and service fields
  - for now we only test pathType:ImplementationSpecific, implemented
    as posix_type re2 matches, which had been the match implementation
    prior to this change.

viking will support the Match and Prefix pathTypes, but in this
iteration, it was not necessary to change the code to support the
ImplementationSpecific pathType.

Examples/tests with kubectl deployments and plain YAML manifests will
also be updated in an upcoming iteration.

In this commit, the code compiles and passes make check. But we
currently can't test anything else, because the manifests/charts
still use API groups that are obsolete in this k8s version.

Cf. ab85c9bb and
c3f7a9a9

The replica scaling test for self-sharding requires the Deployment
name "varnish-ingress" for the viking service.

This is the SNI sent in the client TLS connection to a backend.

We use VMOD dynamic for backends represented by an ExternalName
Service (likely the common use case for TLS onload). VMOD dynamic
does not have the authority field that klarlack makes available
for standard backends. But if the host_header field is set for
a VMOD dynamic director, the VMOD uses that value for the SNI.

So if the BackendConfig authority field is set, we also assign its
value to the host_header field. Since BackendConfig also has a
separate field for host_header, both of them could be conceivably
set to different values. If we find that the two fields are set
to non-empty, conflicting values, the controller emits a
SyncFatalError, and the BackendConfig is not synced.