- as target: client.identity
- as source:
  - client.identity
  - client.ip
  - server.hostname
  - server.identity
  - server.ip
  - remote.ip
  - local.endpoint
  - local.ip
  - local.socket

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.

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.