when replicating

Post-merge fixes. Updating result files.

         when replicating

The function create_virtual_tmp_table does not
set db_low_byte_first in the same way as
create_tmp_table does, causing copying from
the virtual table to a real table to get strange
values for SET types on big-endian machines.

The slave thread changed the format of the information it used to
connect to the master after patch for BUG 13963.  This resulted
in old master getting confused, thence rejecting the slave
connection attempt.

In particular, patch for BUG 13963 removed the rpl_recovery_rank
variable which was, at that time, packed together with the rest
of the information which the slave would use to register itself
on the master. Based on this data, the master would then assert
that the number of bytes received in the connection command was
consistent to what it was expecting. 

Therefore, given that a slave, patched with the aforementioned
patch, would not pack the four bytes related to the
rpl_recovery_rank variable, the old master would reject the
connection attempt. It would assume that the data was
inconsistent (fewer bytes than it was expecting) and return 
an error.

We fix this by faking an rpl_recovery_rank variable when
registering the slave on the master. In practice this reverts a
small part of patch for BUG 13963, the one related to the slave
connecting to the master.

merging from 5.1 to rep+2 starting at gca(5.1, next-mr) == build@mysql.com-20091208092611-pbno5awyb0v38hs7

Fixed conflicts in:

- binlog.binlog_unsafe
- rpl.rpl_slow_query_log

Post-merge fixes to update result files.

         replicating

Fixes to make mysqlbinlog work correctly and updates
to rpl_ndb result files.

Fixes to get it to compile on MacOSX.

Fixing error codes that changed after merge.

           for InnoDB

The class Field_bit_as_char stores the metadata for the
field incorrecly because bytes_in_rec and bit_len are set
to (field_length + 7 ) / 8 and 0 respectively, while
Field_bit has the correct values field_length / 8 and
field_length % 8.

Solved the problem by re-computing the values for the
metadata based on the field_length instead of using the
bytes_in_rec and bit_len variables.

To handle compatibility with old server, a table map
flag was added to indicate that the bit computation is
exact. If the flag is clear, the slave computes the
number of bytes required to store the bit field and
compares that instead, effectively allowing replication
*without conversion* from any field length that require
the same number of bytes to store.

Fixing minor error when printing SQL types from master and cleaning some code.

Updating result files.

Problem: The test was written before BUG#45827 was fixed.
The test contained code that assumed the wrong behavior,
pre-BUG#45827. Then, the fix for BUG#45827 was merged
from 5.1-rep+2 to 5.1-rep+3. Since the test case assumed
the wrong behavior, it failed. This should have been fixed
by making the test assume the correct behavior, but was
fixed by updating the result file to assert failure.
Fix 1: fix the test to assume correct behavior
(post-BUG#45827), update result file.
Fix 2: make test fail with 'die' instead of 'exit' when
wrong behavior is detected. Thus, the test cannot be
silenced with a wrong result file in case the behavior
will change again.

Row-based replication requires the types of columns on the
master and slave to be approximately the same (some safe
conversions between strings are allowed), but does not
allow safe conversions between fields of similar types such
as TINYINT and INT.

This patch implement type conversions between similar fields
on the master and slave.

The conversions are controlled using a new variable
SLAVE_TYPE_CONVERSIONS of type SET('ALL_LOSSY','ALL_NON_LOSSY').

Non-lossy conversions are any conversions that do not run the
risk of losing any information, while lossy conversions can
potentially truncate the value. The column definitions are
checked to decide if the conversion is acceptable.

If neither conversion is enabled, it is required that the
definitions of the columns are identical on master and slave.

Conversion is done by creating an internal conversion table,
unpacking the master data into it, and then copy the data to
the real table on the slave.

Support for flushing individual logs, so that the user can
selectively flush a subset of the server logs.

Flush of individual logs is done according to the 
following syntax:

  FLUSH <log_category> LOGS;

The syntax is extended so that the user is able to flush a
subset of logs:

  FLUSH [log_category LOGS,];

where log_category is one of:
  SLOW
  ERROR
  BINARY
  ENGINE
  GENERAL
  RELAY.

      
Add the test to disabled list and remove from the experimental list.

the last IF ELSE part which decides the plugin name is not relevant as we still have
to substitute the occurences of INNOBASE with INNODB_PLUGIN.
Remove the last IF ELSE part in CMakeLists.txt as it doesn't make sense in 5.1.

manual merge 5.0-->5.1, updating InnoDB plugin.

The bug 38816 changed the lock that protects THD::query from
LOCK_thread_count to LOCK_thd_data, but didn't update the associated
InnoDB functions.

1. The innobase_mysql_prepare_print_arbitrary_thd and the
innobase_mysql_end_print_arbitrary_thd InnoDB functions have been
removed, since now we have a per-thread mutex: now we don't need to wrap
several inter-thread access tries to THD::query with a single global
LOCK_thread_count lock, so we can simplify the code.

2. The innobase_mysql_print_thd function has been modified to lock
LOCK_thd_data in direct way.

and rpl.rpl_get_master_version_and_clock.