External Secret: Implementation to skip the creation of the default u…

[DanielePalaia]

…ser credential secret and give the possibility to use an external one

This closes #

Note to reviewers: remember to look at the commits in this PR and consider if they can be squashed

Summary Of Changes

This changement is adding a new field in the SecretBackend struct of the rabbitmqcluster crd to avoid creating the credential secret for the default user automatically. A secret can be provisioned externally to the operator and be used by the operator using this field.
Pods will remain in init mode till the secret will be provisioned.
It can be useful when an external secret tool (like external secret operator) is used to export a secret from a cloud provider secret management system (like google secret manager).

Additional Context

This can be a first step in order to improve the external secrets management.

Local Testing

Tested both the operator and topology operator system tests against this modification

Please ensure you run the unit, integration and system tests before approving the PR.

To run the unit and integration tests:

$ make unit-tests integration-tests

You will need to target a k8s cluster and have the operator deployed for running the system tests.

For example, for a Kubernetes context named dev-bunny:

$ kubectx dev-bunny
$ make destroy deploy-dev
# wait for operator to be deployed
$ make system-tests

[coro]

Looks like this later gets translated into a LocalObjectReference. Could this type just be a LocalObjectReference upfront? I'd be keen to find out if we get more upfront validation if we were to do that.

[coro]

By upfront validation, I mean would the Kubernetes API reject the request, rather than making it all the way to the controller before rejecting it.

[DanielePalaia]

Hi @coro LocalObjectReference looks good! I modified the type!