AND WEEKLY RUNS

Problem
=======
The test binlog.binlog_stm_drop_tmp_tbl fails on daily and weekly pb2
runs.

ERROR 1051 (42S02) at line 53: Unknown table 'test.t1'
mysqltest: In included file "./extra/binlog_tests/drop_temp_table.test":
included from ./extra/binlog_tests/drop_temp_table.test at line 164:
At line 163: command "$MYSQL < $MYSQLTEST_VARDIR/tmp/bug28642318.sql"
failed

Analysis
========
The test was created to verify the point in time recovery using
mysqlbinlog when the binlogs contained DROP and DELETE queries on
temporary tables.

Test implementation is below:

1. The failing test that was added as part of Bug#28642318 has two
scenarios.

1.1. Test the PITR if the binlog had DELETE query on temporary table.
1.2. Test the PITR if the binlog had DROP query on temporary table.

2. For testing 1.1, we create regular table named 't1' and a temporary
table named 't1' from a different session.

3. We then execute DELETE query and generate .sql file for replaying.

4. We then do binlog replay using `--exec $MYSQL`. Since it is an
asynchronous execution, the test doesn't wait until the connection that
was created as part of the execution is destroyed.

In most of the cases, the connection ends within the scope of the first
scenario(1.1). But, when there is a high load, it could happen that the
connection gets destroyed while the test is executing the second test
scenario(1.2).

When this happens, the server logs
"DROP /*!40005 TEMPORARY */ TABLE IF EXISTS `t1`" command to the new
binary log(test does RESET MASTER before 1.2) during the thread cleanup.

This new additional DROP query drops the table created in 1.2 and in
turn results in the actual DROP query which was supposed to drop the
table get the above mentioned error.

Fix
===
Disable the binary log for the session that will be created by the
execution of `--exec $MYSQL`.

RB: 24007

Reviewed by: Pedro Figueiredo <pedro.figueiredo@oracle.com>