The test fails with timeout when applying diff on two tables.

In this test case, there can be a situation when the slave is not yet synced
with the master, thence the changes may not be on the slave at diff time.

This patch addresses this issue by synchronizing master and slave before the
diff takes place.

conflicts:
  Text conflict in client/mysqltest.cc
  Text conflict in mysql-test/include/wait_until_connected_again.inc
  Text conflict in mysql-test/lib/mtr_report.pm
  Text conflict in mysql-test/mysql-test-run.pl
  Text conflict in mysql-test/r/events_bugs.result
  Text conflict in mysql-test/r/log_state.result
  Text conflict in mysql-test/r/myisam_data_pointer_size_func.result
  Text conflict in mysql-test/r/mysqlcheck.result
  Text conflict in mysql-test/r/query_cache.result
  Text conflict in mysql-test/r/status.result
  Text conflict in mysql-test/suite/binlog/r/binlog_index.result
  Text conflict in mysql-test/suite/binlog/r/binlog_innodb.result
  Text conflict in mysql-test/suite/rpl/r/rpl_packet.result
  Text conflict in mysql-test/suite/rpl/t/rpl_packet.test
  Text conflict in mysql-test/t/disabled.def
  Text conflict in mysql-test/t/events_bugs.test
  Text conflict in mysql-test/t/log_state.test
  Text conflict in mysql-test/t/myisam_data_pointer_size_func.test
  Text conflict in mysql-test/t/mysqlcheck.test
  Text conflict in mysql-test/t/query_cache.test
  Text conflict in mysql-test/t/rpl_init_slave_func.test
  Text conflict in mysql-test/t/status.test

The original goal of the test, as reported on BUG #25721, is to check whether 
a deadlock happens or not when concurrently CREATING/ALTERING/DROPPING the 
same server. For that a procedure (p1) is created that runs the exact same 
CREATE/ALTER/DROP statements for 10K iterations and two different connections 
(threads - t1 and t2) call p1 concurrently. At the end of the 10K iterations, 
the test checks if there was errors while running the loop (SELECT e >0).
      
The problem is that In some cases it may happen that one thread, t1, gets 
scheduled to execute with just enough time to complete the iteration and 
never bumps into the other thread t2. Meaning that t1 will never run into an 
SQL exception. On the other hand, the other thread, t2, may run into t1 and 
never issue any/part of its own statements because it will throw an SQLEXCEPTION. 
This is probably the case for failures where only one value differs.
      
Furthermore, there is a third scenario: both threads are scheduled to run 
interleaved for each iteration (or even one thread completes all iterations 
before the other starts). In this case, both will succeed without any error. 
This is probably the case for the failure that reports two different values.
      
This patch addresses the failure in pushbuild by removing the error counting 
and the printout (SELECT > 0) at the end of the test. A timeout should occur 
if the error that the test is checking surfaces.

 - Additional patch with improved protection by putting it all inside an "eval"
 - Calling 'hostpath' on a truncated socket may also croak.
 - Remove the need to create any directory parts of "path" inside the function.

 - Fix problem with for example ./mtr --timer, caused by new version of "Getopt::Long"
 - Evaluating the "$opt" variable as a string, returns the name of the parameter
   to be modified instead of "Getopt::Long::Callback" which is the class name

In mtr.check_warnings, `text` was declares as type text, which is
64K, and when the server log grows larger than this, it would be
truncated, and then check_warnings was actually checking the 
error messages of a previous test and complain warnings.

This patch fixed the problem by change the type of `text` to
mediumtext, which is 16M.

SIGABRT is sent to relevant processes after a timeout

Log output of mysqltest when running check-testcase together
with errput. Remove --silent option for mysqltest when running
check-testcase/check-warnings

This does not bring any contents changes, it is purely
metadata which are affected.

Details:

Even within 5.0, most of these changesets did not cause
file contents changes, because they were backports done
for the "service pack" builds of 5.0.66sp1 and 5.0.72sp1.

The "real" changesets are also already present in 5.1,
so this upmerge doesn't change any contents.

The only "real" changeset in 5.0 was a fix of the shell
scripts used to configure bdb (BerkeleyDB).
As we completele removed bdb from the 5.1 sources already,
the affected files are not present in the 5.1 source tree,
so this changeset also does not cause any contents changes.

this should not happen.

This is not the final merge of that release build, but we need early
access to these tool fixes (use of "awk" in the BDB configuration).

sync_slave_with_master
 - Additional patch for "disconnect $variable"

Post-fix test failure: fixed mysqlcheck.test on Windows platforms.

bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
triggers
and
#41385: Crash when attempting to repair a #mysql50# upgraded table
with triggers.

Problem:
1. trigger code didn't assume a table name may have
a "#mysql50#" prefix, that may lead to a failing ASSERT().
2. "ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME" failed
for databases with "#mysql50#" prefix if any trigger.
3. mysqlcheck --fix-table-name didn't use UTF8 as a default
character set that resulted in (parsing) errors for tables with
non-latin symbols in their names and definitions of triggers.

Fix:
1. properly handle table/database names with "#mysql50#" prefix.
2. handle --default-character-set mysqlcheck option;
if mysqlcheck is launched with --fix-table-name or --fix-db-name
set default character set to UTF8 if no --default-character-set
option given.

Note: if given --fix-table-name or --fix-db-name option,
without --default-character-set mysqlcheck option
default character set is UTF8.

The next number (AUTO_INCREMENT) field of the table for write
rows events are not initialized, and cause some engines (innodb)
not correctly update the tables's auto_increment value.

This patch fixed this problem by honor next number fields if present.

   41776 type_date.test may fail if run around midnight.
into GCA tree.

The default "awk" there cannot handle some of the scripts
which are used by BDB for configuration.

The fix:
1) Introduce a variable "AWK" in some of the BDB shell scripts,
2) search "gawk" and give it precedence over "awk"
   when assigning a value to the "AWK" variable,
   fail if neither is found,
3) use that variable when calling an "awk" program with one
   of the critical scripts.

The perfect solution would be to use the "awk" program found
by "configure", but we cannot follow that approach because
BDB's configuration is handled as a special case before the
overall "configure" is run. Because of this,
1) the "configure" result isn't yet available,
2) "configure" will not handle these BDB files.
Searching "gawk" is a (not-so-nice) way out.

Note that all this need not be perfectly portable,
it is needed only when we create a source distribution tarball
from a develkopment tree.

   41111 events_bugs fails sporadically on pushbuild
into GCA tree

41932 funcs_1: is_collation_character_set_applicability path too long for tar
into GCA tree

+ add workaround for bug 38124
+ messages into the protocol when sessions are switched
+ replace error numbers by error names
+ reset of system variables to initial values per subtest
+ remove a file created by this test
+ minor improvements in structure and formatting

Added cleanup of status variables to the end of binlog_database.
Re-recorded .result file to account for cleanup statement.
NOTE:  binlog.binlog_innodb also has had an FLUSH STATUS; statement added to it as well, but
adding this cleanup as a preventative measure.