The issue happened to be two-fold.
The table map event was recorded into binlog having
an incorrect size when number of columns exceeded 251. 
The Row-based event had incorrect recording and restoring m_width member within
the same as above conditions.

Fixed with correcting m_data_size and m_width.


mysql-test/suite/rpl/r/rpl_row_wide_table.result:
  the new test results.
mysql-test/suite/rpl/t/rpl_row_wide_table.test:
  regression test for bug#42977.
sql/log_event.cc:
  0. all buffers that used in net_store_length() are augmented with 1 for safety
  to be able to contain the magic and the content of ulonglong as well;
  1. Rows_log_event::get_data_size() yieled incorrect size |m_width/8| whereas 
     it should be m_width;
  2. Table_map_log_event::Table_map_log_event yieled incorrect value for
     `m_data_size' probably presuming 1-byte integer max for the column number;
sql/rpl_utility.h:
  DBUG_PRINT_BITSET() macro is left 256-cols limited but has made safe and commented.

                    expired timeout on debx86-b in PB

Turned off general log when importing DB dump in the test 
case for bug #41486 due to the bug in CSV engine code that 
makes logging long SQL query too slow.

mysql-test/r/mysql-bug41486.result:
  Turned off general log when importing DB dump in the test 
  case for bug #41486 due to the bug in CSV engine code that 
  makes logging long SQL query too slow.
mysql-test/t/mysql-bug41486.test:
  Turned off general log when importing DB dump in the test 
  case for bug #41486 due to the bug in CSV engine code that 
  makes logging long SQL query too slow.

Reset master before next test.

mysql-test/suite/rpl/r/rpl_timezone.result:
  Test result.
mysql-test/suite/rpl/t/rpl_timezone.test:
  Reset master before next test.

                    expired timeout on debx86-b in PB 

Moved the resource-intensive test case for bug #41486 into 
a separate test file to reduce execution time for mysql.test. 


mysql-test/include/wait_until_disconnected.inc:
  Used in mysql-bug41486.test.
mysql-test/r/mysql-bug41486.result:
  Moved the resource-intensive test case for bug #41486 into 
  a separate test file to reduce execution time for mysql.test.
mysql-test/r/mysql.result:
  Moved the resource-intensive test case for bug #41486 into 
  a separate test file to reduce execution time for mysql.test.
mysql-test/t/mysql-bug41486.test:
  Moved the resource-intensive test case for bug #41486 into 
  a separate test file to reduce execution time for mysql.test.
mysql-test/t/mysql.test:
  Moved the resource-intensive test case for bug #41486 into 
  a separate test file to reduce execution time for mysql.test.

LOAD_FILE
            
LOAD_FILE is not safe to replicate in STATEMENT mode, because it
depends on a file (which is loaded on master and may not exist in
slave(s)). This leads to scenarios on which the slave replicates the
statement with 'load_file' and it will try to load the file from local
file system. Given that the file may not exist in the slave filesystem
the operation will not succeed (probably returning NULL), causing
master and slave(s) to diverge. However, when using MIXED mode
replication, this can be made to work, if the statement including
LOAD_FILE is marked as unsafe, triggering a switch to ROW mode,
meaning that the contents of the file are written to binlog as row
events. Consequently, the contents from the file in the master will
reach the slave via the binlog.
           
This patch addresses this bug by marking the load_file function as
unsafe. When in mixed mode and when LOAD_FILE is issued, there will be
a switch to row mode. Furthermore, when in statement mode, the
LOAD_FILE will raise a warning that the statement is unsafe in that
mode.


mysql-test/extra/rpl_tests/rpl_loadfile.test:
  Extra file that is "sourced" on both rpl_loadfile and rpl_stm_loadfile
  test files.
mysql-test/suite/rpl/r/rpl_loadfile.result:
  Updated with the results from the test case added to this file.
mysql-test/suite/rpl/r/rpl_stm_loadfile.result:
  Result file for rpl_loadfile test split with the warnings in statement
  mode.
mysql-test/suite/rpl/t/rpl_loadfile.test:
  After splitting the original rpl_loadfile file, this one is only 
  required to be executed in mixed or row format.
  Appended the test for 39701 to this file.
mysql-test/suite/rpl/t/rpl_stm_loadfile.test:
  Split the original rpl_loadfile test because load_file now raises
  a warning when in statement mode. The goal of this split is 
  two-fold: i) make the test case more resilient; ii) assert that 
  warnings are indeed raised when in statement mode.
sql/item_create.cc:
  Added the set_stmt_unsafe call to lex.

When do 'insert delayed' operation, the time_zone info doesn't be keeped in the row info.
So when we do insert sometime later, time_zone didn't write into binlog.
This will cause wrong result for timestamp column in slave.

Our solution is that adding time_zone info with the delayed-row and
restoring time_zone from row-info when execute that row in the furture by another thread.
So we can write correct time_zone info into binlog and got correct result in slave.


mysql-test/r/rpl_timezone.result:
  Test result
mysql-test/t/rpl_timezone.test:
  Add test for bug#41719
sql/sql_insert.cc:
  Add time_zone info in the delayed-row and restore time_zone when execute the row in the furture by another thread.

   Details for Bug#43015 main.lock_multi: Weak code (sleeps etc.)
   -------------------------------------------------------------
   - The fix for bug 42003 already removed a lot of the weaknesses mentioned.
   - Tests showed that there are unfortunately no improvements of this tests
     in MySQL 5.1 which could be ported back to 5.0.
   - Remove a superfluous "--sleep 1" around line 195

   Details for Bug#43065 main.lock_multi: This test is too big if the disk is slow
   -------------------------------------------------------------------------------
   - move the subtests for the bugs 38499 and 36691 into separate scripts
   - runtime under excessive parallel I/O load after applying the fix
     lock_multi           [ pass ]          22887
     lock_multi_bug38499  [ pass ]         536926
     lock_multi_bug38691  [ pass ]         258498

When asking what database is selected, client expected
to *always* get an answer from the server.

We now handle failure more gracefully.

See comments in ticket for a discussion of what happens,
and how things interlock.


client/mysql.cc:
  Handle empty result-sets gracefully, as opposed
  to just result sets with n>0 items that may themselves
  be empty.

Reviewed fix for bug#37962 also including the revised result files for failing system variable tests.

fix for 29125).