MDEV-37686 rpl.create_or_replace_mix2 fails in MDEV-35915 branch

The test failed as the Jira ticket describes because of insufficient
main transaction isolation from an out-of-band dynamic "new" transaction.
Specifically the replicated transaction's temporary tables became
accessible to the "new" transaction.

The fixes ensure the "new" transaction can't reach any piece of
replication transaction execution context, the temporary table list
including.
This is safe as by so far start_new_trans class instances
need not any replication info, as it must've been anticipated by design.

Author: emoonrain

sql/sql_class.cc

@@ -6359,6 +6359,8 @@ start_new_trans::start_new_trans(THD *thd)
   thd->server_status&= ~(SERVER_STATUS_IN_TRANS |
                          SERVER_STATUS_IN_TRANS_READONLY);
   thd->server_status|= SERVER_STATUS_AUTOCOMMIT;
+  org_rgi_slave= thd->rgi_slave;
+  thd->rgi_slave= NULL;
 }
 
 
@@ -6375,6 +6377,7 @@ void start_new_trans::restore_old_transaction()
     MYSQL_COMMIT_TRANSACTION(org_thd->m_transaction_psi);
   org_thd->m_transaction_psi= m_transaction_psi;
   org_thd->variables.wsrep_on= wsrep_on;
+  org_thd->rgi_slave= org_rgi_slave;
   org_thd= 0;
 }
 

sql/sql_class.h

@@ -5882,6 +5882,11 @@ class start_new_trans
   uint in_sub_stmt;
   uint server_status;
   my_bool wsrep_on;
+  /*
+    THD:rgi_slave may hold a part of the replicated "old" transaction's
+    execution context. Therefore it has to be reset/restored too.
+  */
+  rpl_group_info* org_rgi_slave;
 
 public:
   start_new_trans(THD *thd);