Using a single secret to connect to non operator managed RabbitMQ cluster

[AntonAleksandrov13]

Is your feature request related to a problem? Please describe.
We are running a multi-tenant platform where each tenant requires to have numerous RabbitMQ objects created. Each tenant is has its own namespace. As we use non operator managed RabbitMQ cluster, we have to create a secret object with connection information in each namespace. When a tenant needs to be "destroyed", we would usually delete a namespace object.
Once we have started using the topology operator, we had to rewrite deletion process to delete RMQ objects first. Because if we simply delete a namespace, the connection secret there will be deleted first as it does not require finalizers.
That worked fine until the platform grew significantly where multiple object reconciliation are happening at the same time. That meant there were no guarantee when resources will be deleted. This has resulted in over 150 terminating namespaces with 10-20 objects that operator attempts to reconcile. This adds to the existing load on the operator which affects tenant creation.

Describe the solution you'd like
I propose not to restrict rabbitmqClusterReference.connectionSecret to the namespace where RMQ objects are placed. For example, it's possible to add namespace field to the connectionSecret object. Considering that the operator can already read secrets across multiple namespaces this seems like an okay solution.

Describe alternatives you've considered
From our side we have added checks specifically for RabbitMQ objects during destroy operation. But as I have described above we cannot fully rely on checks if reconciliation time grows.

Alternatively, using RMQ cluster operator can help with this because then we can use reference to RMQ cluster, but this seems like a lenghty migration to a new cluster just to have convenience.

Additional context
I am happy to discuss this proposal and I am willing to contribute.

[Zerpet]

This should be possible since #700. Documenting this enhancement fell through the cracks, unfortunately. We will greatly appreciate if you make a contribution to the docs for this feature: https://github.com/rabbitmq/rabbitmq-website/blob/main/kubernetes/operator/using-topology-operator.md

In summary, the namespace in rabbitmqClusterReference.Namespace is considered for accessing Secrets cross-namespace, as long as the Secret has the annotation rabbitmq.com/topology-allowed-namespaces, following the rules documented here.

[AntonAleksandrov13]

I will review the functionality you have mentioned and contribute to the docs. Thanks a lot!