MDEV-29517: rpl.rpl_change_master_demote sporadically fails in BB

Problem:
=======
Test Case 4 sporadically failed upon waiting for the slave to start during
master demotion to slave, due to a GTID event not existing in the new
master's binlog. If by chance the original slave (new master) did not yet
receive all the binlog events, then this failure could occur.

Solution:
========
Sync slave with master GTID  before master demotion.

Reviewed By:
============
Brandon Nesterenko <brandon.nesterenko@mariadb.com>

mysql-test/suite/rpl/r/rpl_change_master_demote.result

@@ -193,6 +193,9 @@ INSERT INTO t1 VALUES (3);
 # Update to account for statements to verify replication in include file
 CHANGE MASTER TO master_host='127.0.0.1', master_port=SLAVE_PORT, master_user='root', master_use_gtid=slave_pos, master_demote_to_slave=1;
 RESET SLAVE ALL;
+include/save_master_gtid.inc
+connection slave;
+include/sync_with_master_gtid.inc
 include/rpl_change_master_demote.inc
 ##############################################
 # Connection semantics change:

mysql-test/suite/rpl/t/rpl_change_master_demote.test

@@ -143,6 +143,9 @@ INSERT INTO t1 VALUES (3);
 --eval CHANGE MASTER TO master_host='127.0.0.1', master_port=$SLAVE_MYPORT, master_user='root', master_use_gtid=slave_pos, master_demote_to_slave=1
 RESET SLAVE ALL;
 
+--source include/save_master_gtid.inc
+--connection slave
+--source include/sync_with_master_gtid.inc
 --source include/rpl_change_master_demote.inc