The TemplateConfig resource is only read by the controller's k8s client
when the devmode CLI flag is set.

The TemplateConfig spec has fields for the various templates for VCL
generation: ingress, self-sharding, ACL etc. The value type for all
of those fields is string, and each field is optional.

When a TemplateConfig specifies a value for a template type, the
controller attempts to parse it as a text/template.Template, using
the same function map defined for the template type. If the parse
fails, then the error is logged and an Event type Warning with the
error message is generated, and the field is ignored.

If the parse succeeds, then the template is replaced for all further
VCL generation by the controller.

When a TemplateConfig is deleted, then for each template type that it
specifies, the template is reverted to the controller's standard value.

In this first iteration:

- only the ACL template is updated, will add the other types.

- only kubectl deployments are supported, will add support in the
helm chart for the viking controller.

- we have an e2e test, but it is not yet added to the e2e script that
runs all of them, or to the gitlab CI script, since these have to
support helm deployments.

Use a diff package for verbose error display when a gold file does
not match. This has been especially difficult when there are
whitespace mismatches.

Encapsulate the test idiom in a single function. Lotsa DRY.

Tidy up the module list while we're here.

This makes the code less verbose, and more efficient, since the
shard parameters don't need to be fully recomputed each time.

Closes #26

Now consistent with the naming of IngressBackends. Adds the vk8s_
prefix, the namespace and port to the name.

This had been done by querying Pods. It's enough just to query
Endpoints.

This was a remnant of earlier versions when the Pods were set to not
Ready when there is no Ingress to implement. No the Pods are always
ready, but we set the "configured" endpoint to respond with non-200
when nothing is defined.

However, if an Ingress had been defined previously, then deleted,
the http/https endpoints still responded as for the previous config.
This was semantically incorrect, and also meant that the VCL config
remained defined indefinitely. Now it becomes unlabeled, so it can
go cold and then be discarded.

I believe this became necessary because the meaning of the state
and temperature fields in vcl.list has changed in recent Varnish
versions (which we are now using).

This makes backend names more readily recognizable in VCL sources,
and as used in tools such as varnishlog and varnishstat. If the
Pod ns/name is not available, fall back to the previous scheme of
generating names from the Endpoint network addresses.

This makes the naming for Varnish and IngressBackend instances more
legible, and more readily associated with the Pods on which they run,
than by using only network addresses.

First use the names in the controller logs.

This is possible now that we are using Varnish versions that support
return(error(404)) from the backend side. It eliminates unnecessary
computation when a request leads to a cache hit or synthetic response.

It also simplifies the generated VCL code, since the evaluation
happens in one place, rather than in each of hit, miss, pass and
pipe.

Cached responses were interfering with other tests when the e2e test
script was run.

Type declarations in struct literals are unnecessary where the type
is unambiguous.

Forgot it in the previous commit.