Regenerate user passwords when user reconciles

[Martinif]

This closes #242

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

This Pull Request adds an option to always regenerate a user's user-credentials secret when a reconciliation for the user is triggered. The main use case is to update a user's password when the underlying import secret has changed.

Additional Context

A user's login credential are stored in the user-credentials secrets, which are generated at the user creation from an import secret. The documentation instructs us to add a label to trigger user reconciliation when we want to update a users password: https://github.com/rabbitmq/messaging-topology-operator/blob/main/docs/examples/users/README.md

This does however currently not affect a regeneration of the user-credentials secret: s. issue #242

Therefore I added these changes to allow us to force a regeneration when the user is reconciled (e.g. when a label is added).

[vmwclabot]

@Martinif, you must sign our contributor license agreement before your changes are merged. Click here to sign the agreement. If you are a VMware employee, read this for further instruction.

[vmwclabot]

@Martinif, we have received your signed contributor license agreement. The review is usually completed within a week, but may take longer under certain circumstances. Another comment will be added to the pull request to notify you when the merge can proceed.

[vmwclabot]

@Martinif, VMware has approved your signed contributor license agreement.

[Zerpet]

This approach is not going to work. In 9ce8ed9 we removed the RBAC to update secrets, because the Operator was too privileged: it was able to read/list/create/update any secret in any namespace. We removed its ability to update secrets at cluster level, accepting the limitation that the Operator won't be able to update secrets it had created.

Another blocker to accept this contribution is the lack of tests. I caught the above mentioned problem by doing manual QA, which is not desirable.

The most we are willing accept is updating the password if the underlying "user-credentials" Secret changes, taking into consideration the points I raised here: #242 (comment)

[Zerpet]

This PR hasn't seen any activity since October 31st. I'm closing it as stale. Feel free to re-open if there's still interest in driving this PR.