Add rabbitmqClusterReference.connectionSecret

[ChunyiLyu]

This closes #135

Note to reviewers: remember to look at the commits in this PR and consider if they can be squashed
Note to contributors: remember to re-generate client set if there are any API changes

Summary Of Changes

Will be squashed merged due to messy history.
Needs to create a followup for handling TLS connection

Additional Context

[coro]

Will test live now.

[coro]

I'm seeing an issue where if I create a topology object, then the RabbitMQ cluster disappears for whatever reason, the object is stuck in failed delete forever as the operator hits tcp timeouts trying to connect.

In the case where we're using a LocalClusterReference, and we fail to find the RMQ, we assume it's been deleted and we delete the underlying topology object; I'd like to see a similar thing here potentially. There is a trade off, in that a cluster may only be temporarily unavailable while a user does a delete operation, and we'd leave some state around, but I think that's a better solution than having users do a k delete --force.

[coro]

One neat thing this provides is that it solves this issue: #287

[Zerpet]

I'm seeing an issue where if I create a topology object, then the RabbitMQ cluster disappears for whatever reason, the object is stuck in failed delete forever as the operator hits tcp timeouts trying to connect.

In the case where we're using a LocalClusterReference, and we fail to find the RMQ, we assume it's been deleted and we delete the underlying topology object; I'd like to see a similar thing here potentially. There is a trade off, in that a cluster may only be temporarily unavailable while a user does a delete operation, and we'd leave some state around, but I think that's a better solution than having users do a k delete --force.

This behaviour is similar to what's described in #277. Big plus if this PR also fixes that problem.

[coro]

Following on from our chat on Zoom, LGTM! Just one concern about an accidentally included file potentially?