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.

This uses haproxy for TLS connections to IngressBackends, and the
via feature of the klarlack implementation of Varnish. See:

https://github.com/varnishcache/varnish-cache/pull/3128

Adds the spec.tls object to the BackendConfig CRD, which configures
TLS onload for a backend.

Limitations: currently only verify:false and the maxConn settings
are implemented. Specification of CA certificates and the stick
table configuration for haproxy are not yet implemented. Currently
TLS onload may be only specified for one backend (no more than one
BackendConfig).

Adds the CLI option -varnishImpl to the controller. TLS onload is
only supported if this option is set to "klarlack". Otherwise, the
presence of the tls object in a BackendConfig leads to a SyncFatalError,
with a message that it's only supported for klarlack, and the
BackendConfig is not synced.

If the backend Service specified for TLS onload has type ExternalName,
then 3 server instances are configured for the haproxy backend. This
value is currently hard-wired, and may be made configurable in a future
iteration. For any other Service type, there are as many haproxy server
instances as there are Endpoints (Pods) in the k8s cluster.

If maxConn is not specified in the BackendConfig, it defaults to
2000 (the haproxy default).

See c3f7a9a9

If changes did not trigger a klarlack build, gitlab CI would file this
complaint:

  Found errors in your .gitlab-ci.yml:

    'build:ascn' job needs 'build:klarlack' job
    but 'build:klarlack' is not in any previous stage

despite the fact that the ci file lints just fine.

IIUC, the issue is that for the triggered pipeline, the klarlack build job
just would not exist.

In this case, we can build ascn on top of the previous klarlack build.

Does this help?