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).

with mysql_change_user) to 5.0.

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.

The problem is that the query cache stores packets containing
the server status of the time when the cached statement was run.
This might lead to a wrong transaction status in the client side
if a statement is cached during a transaction and is later served
outside a transaction context (and vice-versa).

The solution is to take into account the transaction status when
storing in and serving from the query cache.

   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

      
The greedy optimizer tracks the current level of nested joins and the position
inside these by setting and maintaining a state that's global for the whole FROM
clause.
This state was correctly maintained inside the selection of the next partial plan
table (in best_extension_by_limited_search()). 
greedy_search() also moves the current position by adding the last partial match 
table when there's not enough tables in the partial plan found by 
best_extension_by_limited_search().
This may require update of the global state variables that describe the current
position in the plan if the last table placed by greedy_search is not a top-level 
join table.
Fixed by updating the state after placing the partial plan table in greedy_search()
in the same way this is done on entering the best_extension_by_limited_search().
Fixed the signature of the function called to update the state : 
check_interleaving_with_nj

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.

Bug#36428: MY_MUTEX_INIT_FAST is used before initialization

On some thread implementations, we need a fake mutex attri-
bute as a placeholder, which we define as a global variable,
"my_fast_mutexattr".  Well. that must be initialized before 
used in any mutexes, and the ordering of initializations in 
the API function  my_init()  was wrong.

Now, put my_thread_global_init(), which initializes the attri-
butes that mutexes require.