MDEV-32953: main.rpl_mysqldump_slave Fails with "Master binlog wasn’t deleted" Assertion

Because --delete-master-logs immediately purges logs after flushing,
it is possible the binlog dump thread would still be using the old
log when the purge executes, disallowing the file from being
deleted.

This patch institutes a work-around in the test as follows:
 1) temporarily stop the slave so there is no chance the old binlog
is still being referenced.
 2) set master_use_gtid=Slave_pos so the slave can still appear
up-to-date on the master after the master flushes/purges its logs
(while the slave is offline). Otherwise (i.e. if using binlog
file/pos), the slave would point to a purged log file, and receive
an error immediately upon connecting to the master.

Reviewed By
============
Andrei Elkin <andrei.elkin@mariadb.com>

mysql-test/main/rpl_mysqldump_slave.result

@@ -72,6 +72,13 @@ id int
 insert into t values (1);
 insert into t values (2);
 drop table t;
+connection slave;
+include/stop_slave.inc
+change master to master_use_gtid=slave_pos;
+connection master;
+# Ensuring the binlog dump thread is killed on primary...
 -- CHANGE MASTER TO MASTER_LOG_FILE='master-bin.000002', MASTER_LOG_POS=BINLOG_START;
 -- SET GLOBAL gtid_slave_pos='0-1-1005';
+connection slave;
+include/start_slave.inc
 include/rpl_end.inc

mysql-test/main/rpl_mysqldump_slave.test

@@ -85,7 +85,7 @@ DROP TABLE t2;
 
 #
 # MDEV-32611 Added test for mysqldump --delete-master-logs option.
-# This options is alias of 
+# This options is alias of
 # get binlogs: show master status -> flush logs -> purge binary logs to <new_binlog>
 # sequence and this test is derived using the same pattern.
 #
@@ -101,6 +101,33 @@ insert into t values (2);
 
 drop table t;
 
+--sync_slave_with_master
+
+# MDEV-32953: Because --delete-master-logs immediately purges logs after
+# flushing, it is possible the binlog dump threads will still be using the old
+# log when the purge executes, disallowing the file from being deleted.
+# Therefore, we temporarily stop the slave so there is no chance the old binlog
+# is still being referenced. master_use_gtid=Slave_pos is necessary to still
+# appear up-to-date to the master on restart after the master has flushed the
+# logs (while the slave is offline). Otherwise (i.e. if using binlog file/pos),
+# the slave would point to a purged log file, and receive an error immediately
+# upon connecting to the master.
+--source include/stop_slave.inc
+change master to master_use_gtid=slave_pos;
+
+connection master;
+
+--echo # Ensuring the binlog dump thread is killed on primary...
+--disable_query_log
+--let $binlog_dump_thd_tid= `SELECT ID FROM INFORMATION_SCHEMA.PROCESSLIST WHERE COMMAND LIKE 'Binlog Dump'`
+if ($binlog_dump_thd_tid)
+{
+  --eval kill $binlog_dump_thd_tid
+}
+--let $wait_condition= SELECT COUNT(*)=0 FROM INFORMATION_SCHEMA.PROCESSLIST WHERE COMMAND LIKE 'Binlog Dump'
+--source include/wait_condition.inc
+--enable_query_log
+
 --let $predump_binlog_filename= query_get_value(SHOW MASTER STATUS, File, 1)
 
 # Execute mysqldump with delete-master-logs option
@@ -125,4 +152,7 @@ if ($postdump_first_binary_log_filename != $postdump_binlog_filename)
   --die Master binlog wasn't deleted after mariadb-dump with --delete-master-logs.
 }
 
+connection slave;
+--source include/start_slave.inc
+
 --source include/rpl_end.inc