VaultDynamicSecrets do not revoke lease when associated kubernetes secret is deleted

[dcaputo-harmoni]

Describe the bug
When the kubernetes secret associated with a VaultDynamicSecret is deleted, the VSO requests a new lease and recreates the secret with the newly leased credentials. But the VSO does not revoke the previous lease before doing so, resulting in orphaned leases. Since the kubernetes secret is the only place that these credentials are used, it is effectively a proxy for the lease - and deleting it should revoke the lease. Or at a minimum, there should be an option to revoke the lease on secret deletion.

To Reproduce
Steps to reproduce the behavior:

1. Deploy a VaultDynamicSecret
2. Delete the associated kubernetes secret
3. A new lease will be obtained and a new kubernetes secret will be created
4. The previous lease will remain in place

[dcaputo-harmoni]

One further thought on this - it could behave just like the revoke: true flag within the VaultDynamicSecret spec, however the trigger would also encompass deletion of the underlying kubernetes secret. It could be encompassed within the revoke setting (where setting to true triggers a revoke on either the VDS deletion or secret deletion), it could be a separate boolean setting such as revokeOnSecretDeletion, or make revoke a string or array setting that allows specifying which triggers would revoke - VDS, secret or both.

[benashz]

Thanks @dcaputo-harmoni, that's a good call out.