Uses a leader-elector sidecar to ensure only one injector replica
generates the CA and cert+key. The other replicas pick up the cert+key
from a k8s secret for use in their TLS listeners.

The leader-elector sidecars coordinate using the annotations of a k8s
Endpoint object, which is why those extra permissions were added to
the role in the deployment yaml.

Build a dev image: `make image VERSION=dev`
Deploy: `kubectl apply -k deploy/ -n vault`

Added command-line and env option to control leader-elector
usage. Using Secrets informer for followers to ensure retrieving
timely cert updates without overloading the k8s api.

Added ttl and health checks to leader-elector. Added
AGENT_INJECT_USE_LEADER_ELECTOR env option to deployment.

Slightly refactored the leader package so it's more testable

Co-authored-by: Tom Proctor <tomhjp@users.noreply.github.com>

…r' into VAULT-84/leader-elector-container

Using the community gcr registry (k8s.gcr.io), election arg to match
the endpoint deploy yaml, and updating the secret name to match the
code.

…ctor-container

To ensure the behavior is unchanged for users not using the leader
elector logic.

Passing the CA around in the Secret seemed to prevent followers from
recreating a CA if they're promoted to leader. Since the followers
don't need the CA, removed it from the Secret.

Added a named logger to GenSource (auto-tls), mostly debug-level for
telling which is the leader and which is the follower.

While the leader is waiting for the current certificate to expire, a
leadership change could occur, and then the former leader's
certificate would be out of sync with the new leader. Added a
goroutine that signals a channel on a leadership change.