Due to the @cache decorator in the code, it was possible to get the
charm into a state where RMQ is clustered, but the charm doesn't record
it. The charm 'thinks' it is clustered when it has set the 'clustered'
key on the 'cluster' relation. Unfortunately, due to the @cached
decorator it's possible in the 'cluster-relation-changed' hook to have a
situation where the RMQ instance clusters during the hook execution and
then, later, when it's supposed to writing the 'clustered' key, it reads
the previous cached value where it wasn't clustered and therefore
doesn't set the 'clustered' key. This is just about the only
opportunity to do it, and so the charm ends up being locked.
The fix was to clear the @cache values so that the nodes would be
re-read, and this allows the charm to then write the 'clustered' key.
Change-Id: I12be41a83323d150ba1cbaeef64041f0bb5e32ce
Closes-Bug: #1975605
81f08ab769