Bug #28774259 : LOCK_ORDER: DEADLOCK INVOLVING MASTER_KEY_ID_MUTEX

Issue:
 For two threads T1 and T2 where
  T1 : DROP TABLE t1;
  T2 : CREATE TABLESPACE encrypt_ts ADD DATAFILE 'encrypt_ts.ibd' ENCRYPTION='Y';

 Following is a possible deadlock scenario where :
  T1 : Holding (mutex on master_key_id_mutex) : Requesting (dict_sys->mutex)
  T2 : Holding (dict_sys->mutex) : Requesting (mutex on master_key_id_mutex)

Fix:
 In replay_delete_space_log(), take mutex on master_key_id_mutex, after releasing
 dict_sys->mutex to make sure there is no wait cycle.

RB : 20745
Reviewed by : Annamalai Gurusami <annamalai.gurusami@oracle.com>

Author: mayprasa

storage/innobase/log/log0ddl.cc

@@ -1542,11 +1542,6 @@ void Log_DDL::replay_delete_space_log(space_id_t space_id,
     undo::spaces->x_unlock();
   }
 
-  /* Require the mutex to block key rotation. Please note that
-  here we don't know if this tablespace is encrypted or not,
-  so just acquire the mutex unconditionally. */
-  mutex_enter(&master_key_id_mutex);
-
   if (thd != nullptr) {
     /* For general tablespace, MDL on SDI tables is already
     acquired at innobase_drop_tablespace() and for file_per_table
@@ -1556,6 +1551,11 @@ void Log_DDL::replay_delete_space_log(space_id_t space_id,
     mutex_exit(&dict_sys->mutex);
   }
 
+  /* Require the mutex to block key rotation. Please note that
+  here we don't know if this tablespace is encrypted or not,
+  so just acquire the mutex unconditionally. */
+  mutex_enter(&master_key_id_mutex);
+
   DBUG_EXECUTE_IF("ddl_log_replay_delete_space_crash_before_drop",
                   DBUG_SUICIDE(););