Update secret version hashing algorithm

[tomhjp]

Updates the version generation algorithm to include an HMAC key. On each mount request, the provider will try to read the HMAC key from a Kubernetes secret and race to create it if not found. This ensures each provider produces consistent versions, and also makes recovering from unexpected errors easy (an admin just deletes the secret) without introducing the complexity and overhead of leader elections.

The PR also makes generating versions best-effort. If we can't use an HMAC key, we log a warning and revert to our pre-1.2.0 behaviour of not reporting a version at all, as consistency and reliability seem much more important than accurate version reporting. If versions thrash about unnecessarily it will cause lots of thrashing for any systems that observe the version.

Sorry for the size. I also made a feature to specify custom metadata for the created secret in 4b422ed, but felt it wasn't quite straightforward enough so took that feature out for the initial PR to keep the size lower. The idea was to replicate the pod's metadata, but there are certain pod-specific labels you'd want to filter out like controller-revision-hash and pod-template-generation. I'll try to refine that idea and follow up in another PR.

[swenson]

LGTM; one suggestion

[tvoran]

The reactor usage in the tests is really nice!