Update rabbitmq OCF script to protect against failed status

In rare cases, the rabbitmq status check may return a status of '2',
which is an indication to the OCF script that the rabbitmq-server is
not running, but it may be at least partially up. In such a case, SM
will see this as a failure of the service when it calls the OCF status
check, but will subsequently fail to relaunch the service due to the
partial status of the already-running service.

To help avoid this, this commit updates the OCF script to:
1. Update the "stop" function to attempt "rabbitmqctl stop" regardless
of the "status" result. If the service is partially running, this
should tear it down.
2. Update the "start" script to call the "stop" function prior to
attempting to launch the service, in case it is partially running.

Change-Id: I19842d382dd1ab60b1caade6608f8dbb9257ebbe
Closes-Bug: 1896697
Signed-off-by: Don Penney <don.penney@windriver.com>

rabbitmq-server-config/centos/build_srpm.data

@@ -1,2 +1,2 @@
 SRC_DIR="files"
-TIS_PATCH_VER=0
+TIS_PATCH_VER=PKG_GITREVCOUNT

rabbitmq-server-config/files/rabbitmq-server.ocf

@@ -302,6 +302,10 @@ rabbit_start() {
         return $OCF_SUCCESS
     fi
 
+    # Call rabbit_stop, just in case something's still running
+    ocf_log info "Calling rabbit_stop ahead of rabbit_start"
+    rabbit_stop
+
     export_vars
 
     # Increase the maximum number of file descriptors that can be open at
@@ -346,7 +350,12 @@ rabbit_stop() {
 
     if ! rabbit_status; then
         ocf_log info "Resource not running."
-        return $OCF_SUCCESS
+
+        # On rare occasions, the status check could indicate rabbitmq is not running,
+        # but there could be partial service. As such, ignore this case and just fall
+        # through to continue with the stop
+        #
+        # return $OCF_SUCCESS
     fi
 
     $RABBITMQ_CTL stop