Stop of rabbit app within start_rmq_server_app (OCF `rabbitmq-server-ha`)

Hi,

in the OCF file **rabbitmq-server-ha**, I don't understand why after a successful start, the function `stop_rmq_server_app` is called.
https://github.com/ClusterLabs/resource-agents/blob/50b6cd7d363e1208379c12349a2f3a2a83b8999c/heartbeat/rabbitmq-server-ha#L1402

As seen in snippet below, why would I want to stop the rmq server app when it just was started successfully as master of cluster:

```
if [ $rc -eq $OCF_SUCCESS ] ; then
# rabbitmq-server started successfuly as master of cluster
master_score $MIN_MASTER_SCORE
stop_rmq_server_app
rc=$?
if [ $rc -ne 0 ] ; then
ocf_log err "${LH} RMQ-server app can't be stopped. Beam will be killed."
kill_rmq_and_remove_pid
unblock_client_access "${LH}"
return $OCF_ERR_GENERIC
fi
```

Clearly I am missing something, could someone please explain why it is done this way? @bogdando maybe can you help me out here?

We are using OCF rabbitmq-server-ha within a pacemaker cluster of 3 nodes and experience slow starts and a somewhat strange master election of the RabbitMQ master (newly booted node tears down active master and starts its own promotion...)

Start with heartbeat/rabbitmq-server-ha around the linked line and trace stop_rmq_server_app within the start path. Review the surrounding cluster-start and master-election logic first, then compare the observed slow starts and unexpected promotion with the agent's intended behavior. Done should explain or correct the stop and election behavior and verify it in a three-node Pacemaker setup.

Written by the indexing model from the issue text.