MDEV-13472 rpl.rpl_semi_sync_wait_point crashes because of thd_destru…

…ctor_proxy

The thd_destructor_proxy detects that no transactions are active and
starts srv_shutdown_bg_undo_sources(), but fails to take into account
that new transactions can still start, especially be slave but also
by other threads. In addition there is no mutex when checking for
active transaction so this is not safe.

We relax the failing InnoDB debug assertion by allowing the execution
of user transactions after the purge thread has been shut down.

FIXME: If innodb_fast_shutdown=0, we should somehow guarantee that no
new transactions can start after thd_destructor_proxy observed that
trx_sys_any_active_transactions() did not hold.

storage/innobase/trx/trx0purge.cc

@@ -293,14 +293,16 @@ trx_purge_add_update_undo_to_history(
 
 	After the purge thread has been given permission to exit,
 	in fast shutdown, we may roll back transactions (trx->undo_no==0)
-	in THD::cleanup() invoked from unlink_thd(). */
+	in THD::cleanup() invoked from unlink_thd(), and we may also
+	continue to execute user transactions. */
 	ut_ad(srv_undo_sources
 	      || ((srv_startup_is_before_trx_rollback_phase
 		   || trx_rollback_or_clean_is_active)
 		  && purge_sys->state == PURGE_STATE_INIT)
 	      || (srv_force_recovery >= SRV_FORCE_NO_BACKGROUND
 		  && purge_sys->state == PURGE_STATE_DISABLED)
-	      || (trx->undo_no == 0 && srv_fast_shutdown));
+	      || ((trx->undo_no == 0 || trx->in_mysql_trx_list)
+		  && srv_fast_shutdown));
 
 	/* Add the log as the first in the history list */
 	flst_add_first(rseg_header + TRX_RSEG_HISTORY,