MDEV-33133: MDL conflict handling code should skip BF-aborted trxs

It's possible that MDL conflict handling code is called more
than once for a transaction when:
- it holds more than one conflicting MDL lock
- reschedule_waiters() is executed,
which results in repeated attempts to BF-abort already aborted
transaction.
In such situations, it might be that BF-aborting logic sees
a partially rolled back transaction and erroneously decides
on future actions for such a transaction.

The specific situation tested and fixed is when a SR transaction
applied in the node gets BF-aborted by a started TOI operation.
It's then caught with the server transaction already rolled back,
but with no MDL locks yet released. This caused wrong state
detection for such a transaction during repeated MDL conflict
handling code execution.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

sql/wsrep_mysqld.cc

@@ -3138,8 +3138,6 @@ void wsrep_handle_mdl_conflict(MDL_context *requestor_ctx,
     {
       DBUG_ASSERT(granted_thd->wsrep_aborter == request_thd->thread_id);
       WSREP_DEBUG("BF thread waiting for a victim to release locks");
-      mysql_mutex_unlock(&granted_thd->LOCK_thd_data);
-      mysql_mutex_unlock(&granted_thd->LOCK_thd_kill);
     }
     else if (wsrep_thd_is_toi(granted_thd) ||
              wsrep_thd_is_applying(granted_thd))
@@ -3218,13 +3216,12 @@ void wsrep_handle_mdl_conflict(MDL_context *requestor_ctx,
     }
     mysql_mutex_unlock(&granted_thd->LOCK_thd_data);
     mysql_mutex_unlock(&granted_thd->LOCK_thd_kill);
+    DEBUG_SYNC(request_thd, "after_wsrep_thd_abort");
   }
   else
   {
     mysql_mutex_unlock(&request_thd->LOCK_thd_data);
   }
-
-  DEBUG_SYNC(request_thd, "after_wsrep_thd_abort");
 }
 
 /**/