MDEV-10793: MDEV-33292: main.kill_processlist-6619 fails sporadically in buildbot

There were several races in the main.kill_processlist-6619 testcase:

 - Lingering connections from a previous test case could be visible in SHOW
   PROCESSLIST and cause .result diff.
 - A sync point "dispatch_command_end" was ineffective, as it was consumed at
   the end of the SET DEBUG command itself.
 - The signal from sync point "before_execute_sql_command" could override an
   earlier signal, causing DEBUG_SYNC timeout and test failure.
 - The final SHOW PROCESSLIST could occasionally see a connection in state
   "Busy" instead of the expected "Sleep".
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>

mysql-test/main/kill_processlist-6619.result

-SET DEBUG_SYNC='dispatch_command_end SIGNAL ready WAIT_FOR go';
-select 1;
+SET DEBUG_SYNC='dispatch_command_end2 SIGNAL ready EXECUTE 3';
 connect  con1,localhost,root,,;
 SET DEBUG_SYNC='now wait_for ready';
+connection default;
+SET DEBUG_SYNC='dispatch_command_end WAIT_FOR go EXECUTE 2';
+select 1;
+connection con1;
 SET DEBUG_SYNC='now signal go';
+SET DEBUG_SYNC='now wait_for ready';
+SET DEBUG_SYNC='now signal go';
+SET DEBUG_SYNC='now wait_for ready';
+SET DEBUG_SYNC='RESET';
 SHOW PROCESSLIST;
 Id	User	Host	db	Command	Time	State	Info	Progress
 #	root	#	test	Sleep	#	#	NULL	0.000

mysql-test/main/kill_processlist-6619.test

@@ -4,13 +4,34 @@
 --source include/not_embedded.inc
 --source include/have_debug_sync.inc
 
+# Ensure no lingering connections from an earlier test run, which can very
+# rarely still be visible in SHOW PROCESSLIST here.
+--let $wait_condition= SELECT COUNT(*) = 1 from information_schema.processlist
+--source include/wait_condition.inc
+
 # This is to ensure that the following SHOW PROCESSLIST does not show the query
-SET DEBUG_SYNC='dispatch_command_end SIGNAL ready WAIT_FOR go';
+#
+# The use of DEBUG_SYNC here is quite tricky, and there were several bugs in
+# this test case before. The dispatch_command_end* sync points will trigger at
+# the end of the statement that sets them, so we need to use EXECUTE 2/3 to
+# make them trigger also during the "select 1" statement. And we need to use
+# two separate sync points so that we can wait first and signal after;
+# otherwise the last wait from dispatch_command_end may time out as its signal
+# gets overridden from the later sync point "before_execute_sql_command".
+#
+SET DEBUG_SYNC='dispatch_command_end2 SIGNAL ready EXECUTE 3';
+--connect (con1,localhost,root,,)
+SET DEBUG_SYNC='now wait_for ready';
+--connection default
+SET DEBUG_SYNC='dispatch_command_end WAIT_FOR go EXECUTE 2';
 --send select 1
 
---connect (con1,localhost,root,,)
+--connection con1
+SET DEBUG_SYNC='now signal go';
 SET DEBUG_SYNC='now wait_for ready';
 SET DEBUG_SYNC='now signal go';
+SET DEBUG_SYNC='now wait_for ready';
+SET DEBUG_SYNC='RESET';
 
 --let $con_id = `SELECT CONNECTION_ID()`
 --replace_result Execute Query
@@ -36,7 +57,7 @@ SET DEBUG_SYNC='reset';
 # Wait until default connection has reset query string
 let $wait_condition=
   SELECT COUNT(*) = 1 from information_schema.processlist
-  WHERE info is NULL;
+  WHERE Command = "Sleep" AND info is NULL;
 --source include/wait_condition.inc
 
 --replace_result Execute Query

sql/sql_parse.cc

@@ -2504,6 +2504,7 @@ bool dispatch_command(enum enum_server_command command, THD *thd,
     MYSQL_COMMAND_DONE(res);
   }
   DEBUG_SYNC(thd,"dispatch_command_end");
+  DEBUG_SYNC(thd,"dispatch_command_end2");
 
   /* Check that some variables are reset properly */
   DBUG_ASSERT(thd->abort_on_warning == 0);