BUG#53101: binlog.binlog_tmp_table fails on sol10 sparc64 max in

           parallel mode
      
The failure has nothing to do with parallel, but rather on the
order the tests are executed. In this case, the test
binlog_tmp_table (lets call it test2) was not ensuring that the
binary logs would be reset when it started. Later the test issues
a mysqlbinlog .../master-bin.000002 | mysql ... If the test that
was executed before this one (lets call it test1) had issued a
flush logs, then the file in use in test1 (master-bin.000002)
would not actually match the one that was expected. Eventually,
this would cause the statements logged in test1 to be replayed,
instead of the ones logged in the beginning of test2.
    
We fix this by:
  1. adding RESET MASTER to the beginning of binlog_tmp_table
  2. setting dynamically the file to use in binlog_tmp_table
     
Only #1 was needed, but the two make the tests cases more robust.

mysql-test/suite/binlog/r/binlog_tmp_table.result

+RESET MASTER;
 create table foo (a int);
 flush logs;
 create temporary table tmp1_foo like foo;

mysql-test/suite/binlog/t/binlog_tmp_table.test

@@ -28,6 +28,8 @@
 source include/have_log_bin.inc;
 source include/have_binlog_format_mixed_or_statement.inc;
 
+RESET MASTER;
+
 --disable_query_log
 CALL mtr.add_suppression("Unsafe statement binlogged in statement format since BINLOG_FORMAT = STATEMENT");
 --enable_query_log
@@ -71,6 +73,8 @@ truncate table tmp1_foo;
 connection master1;
 truncate table tmp2_foo;
 
+let $binlog_file= query_get_value(SHOW MASTER STATUS, File, 1);
+
 flush logs;
 
 connection default;
@@ -82,7 +86,7 @@ create table foo (a int);
 
 # replay from binary log
 let $MYSQLD_DATADIR= `select @@datadir`;
-exec $MYSQL_BINLOG $MYSQLD_DATADIR/master-bin.000002 | $MYSQL;
+exec $MYSQL_BINLOG $MYSQLD_DATADIR/$binlog_file | $MYSQL;
 select * from foo;
 
 # clean up