4.1, by @Ayanda-D: stop QQ replicas when a QQ is forced to shrink to a single replica

[michaelklishin]

This is #12427 by @Ayanda-D.

Shrinking operations did not stop QQ replicas. This was easy to miss because QQs are usually shrunk before a node is removed from the cluster.

However, there is a scenario where this is not the case. If some nodes (replicas) need to be replaced, in particular when a majority of nodes cannot be recovered for any reasons, the recovery process will involve shrinking a QQ to just one member so that it has an online quorum (of 1 node out of 1) before new replicas can be added.

For this to succeed, the older replicas must be stopped and deleted from the (QQ) cluster.

[michaelklishin]

@Ayanda-D the failure on Erlang 27 in ct_logs have nothing to do with this change. Nonetheless, this PR may have to wait until more CI-related changes land into main.

[michaelklishin]

The failures seem to be unrelated to the changes here.

See erlang/otp#8908 and erlang/otp#8911.

[mergify]

backport v4.0.x v3.13.x

✅ Backports have been created

• #12481 4.1, by @Ayanda-D: stop QQ replicas when a QQ is forced to shrink to a single replica (backport #12468) has been created for branch v4.0.x but encountered conflicts
• #12482 4.1, by @Ayanda-D: stop QQ replicas when a QQ is forced to shrink to a single replica (backport #12468) has been created for branch v3.13.x but encountered conflicts

[Ayanda-D]

@michaelklishin Thank you! 🙏

[Ayanda-D]

cc: @willhoy @ahsanabbas123 @25schmekles @mlongob @ThisIsNSH

[michaelklishin]

FTR, this was backported to v4.0.x manually.

v3.13.x is now only covered by commercial support so if we backport this change to v3.13.x, it will ship in the commercial edition (Tanzu RabbitMQ).