[Feature] Integration with HashiCorp Vault and its database secret engine

Currently the Postgres Operator is able to manage roles it receives from multiple sources (manifest, infrastructure, teams) within the PostgreSQL instance (https://github.com/zalando/postgres-operator/blob/master/docs/user.md#defining-database-roles-in-the-operator).

While this is really quite powerful, we would like to extend further on this and optionally allow to use HashiCorp Vault and its database secrets engine to manage secrets and hand
out credentials to individual pods and application instances. Vault adds dynamic credentials and strong audit capabilities. Short lived credentials reduce the risk of secret
sprawl and also allow identification of a security breach by having client specific credentials.

At its core this feature would require the operator to register each PostgreSQL instance with Vault and provide superuser credentials in order for Vault to take over the secret managment (https://www.vaultproject.io/api/secret/databases/index.html#configure-connection).
To enable Vault to hand out credentials for certains PostgreSQL roles, those might need to be defined as well (https://www.vaultproject.io/api/secret/databases/index.html#create-role),
but analogous to infrastructure roles they can be static (https://www.vaultproject.io/docs/secrets/databases/index.html#static-roles).
HashiCorp already provides a Golang library for the API and also maintains a Terraform provider (https://github.com/terraform-providers/terraform-provider-vault) using it.
Using similar calls towards the Vault API instead of running against the PostgreSQL instances itself would need to be added to the sync loop
then (https://github.com/zalando/postgres-operator/blob/master/pkg/cluster/sync.go).
Kubernetes Secrets would then not be created anymore as they shall remain inside Vault.
Our intention regarding a Vault integration is for it to be an optional and non-breaking extension on the current capabilities by no means a replacement - Not everybody requires/wants to use Vault.

With a few integration points / conditionals in the sync.go loop all other code handling the integration could be held to a different module. A configuration switch to enable this feature and then a Kubernetes Secret holding the settings to configure the Vault provisioning client (to register / delete databases) inside the operator and its behavior would likely be enough and keeps those domains separate while having a joint sync loop to have the PostgreSQL instance as well as the database registered in Vault.

The client side of things, as in requesting a token and then PostgreSQL credentials from Vault is totally out of scope for this feature as this is agnostic from the "source"
of PostgreSQL instances anyways. This can be achieved by enabling the application / framework to talk to Vault (i.e. SpringBoot https://spring.io/guides/gs/vault-config/)
or to run a sidecar with i.e. ConsulTemplate + pgbouncer keeping all this complexity away from the clients. But this is no job for a PostgreSQL operator, but rather something more
in the domain of Vault or the applications themselves.

To cut a long story short, we'd like to discuss if others also see value in integrating with Vault
to manage secrets and consequently if you you might accept a PR from our side.

Start with pkg/cluster/sync.go and the linked PostgreSQL role-management documentation, then review the referenced Vault database secrets API for registration, connection configuration, and roles. The issue proposes an optional configuration switch and separate provisioning module while keeping client-side credential retrieval out of scope. Done would mean an agreed design and accepted implementation for non-breaking Vault integration without creating Kubernetes Secrets.