Deployment is now in the API group apps/v1.

RBAC for the namespace example was missing rules to access resources
in the ingress.varnish-cache.org APIs.

Otherwise no backend is set for background fetches.

Newer versions of the RPMs for compatibility with Varnish 6.2
evidently do not express dependencies narrowly enough.

Closes #24

Reduces repetition in the code. The CRD limits the comparison
operations permitted for certain configs (ACL, rewrite,
req-disposition).

Ref #24

Silences a golint "stutter" warning.

Silences a golint "stutter" warning.

The error channel for the Varnish controller was never used.
The Varnish controller uses a WaitGroup to wait for any running
admin interactions with Varnish instances to complete before
shutting down.

Closes #6

Generated code in pkg/apis and pkg/client has no tests, and fails
golint noisily, but none of it is actionable.

This has exposed k8s issue #59822 when we use client-go v6.0.0 for
compatibility with k8s 1.9, when shared informers are stopped as
part of queue shutdown:

https://github.com/kubernetes/kubernetes/issues/59822

This upgrades to use of client-go v6.0.1, but evidently only has the
effect that the problem is intermittent. Occasionally there are panics
due to double channel close. The guarantee of sequential delivery
by a shared informer may also not be honored.

We go forward with these issues, since 1.9 is already out of support,
and will probably start supporting newer k8s versions in the near
term.

Ref #6

Closes #7

Notifications from the API server (Add, Delete, Update) are now
logged at the Debug level.

Details of the monitor loop are also at the Debug level when all is
well, for example when there are no panics, child is running, etc.

Otherwise, messages previously at the Debug level are now at the
Trace level -- logging to trace and debug what the controller is
doing.

This is a best practice for Varnish and should be encouraged by the
example configs.

In order to avoid return(pass) in builtin vcl_recv when
req.http.Authorization is present -- if the backends don't need the
header, it can be deleted. But we need to make sure that it isn't
removed before the auth protocol is executed.