Modular Secret Backend Epic

[adejanovski]

Background

K8ssandra v1.x and K8ssandra-operator only work with Kubernetes secrets as secret provider. This prevents companies using K8ssandra if their security policy doesn’t allow usage of Kubernetes secrets.
We would need to provide an API that has the following characteristics:

• Secrets should be injectable into pods directly, without requiring access from the operators
• Secrets providers should be pluggable without requiring implementation specific code in K8ssandra-operator or cass-operator (generic external provider)
• It should be possible to add providers at runtime
• Secrets should be mounted in a common way so that the operator can perform validation checks using a validation webhook
• Management of default secrets should be disabled when using an external provider

Design

This proposal leverages dynamic admission control to allow extension at runtime, without recompiling or redeploying K8ssandra-operator.

This design is widely inspired by the Hashicorp Vault agent which uses the same technique for secrets injection at runtime.

### Tasks
- [x] #599
- [x] #600
- [x] #606
- [x] #501
- [ ] #601
- [ ] #602
- [ ] #603
- [ ] #604
- [ ] #605
- [ ] #607
- [ ] #608
- [ ] https://github.com/thelastpickle/cassandra-reaper/issues/1210
- [x] https://github.com/thelastpickle/cassandra-medusa/issues/493
- [ ] https://github.com/k8ssandra/cass-operator/issues/520
- [ ] https://github.com/k8ssandra/k8ssandra-operator/issues/964
- [ ] https://github.com/k8ssandra/k8ssandra-operator/issues/965

┆Issue is synchronized with this Jira Story by Unito
┆Issue Number: K8OP-183