RBR was not considering the option --slave-skip-errors.
                              
To fix the problem, we are reporting the ignored ERROR(s) as warnings thus avoiding 
stopping the SQL Thread. Besides, it fixes the output of "SHOW VARIABLES LIKE 
'slave_skip_errors'" which was showing nothing when the value "all" was assigned 
to --slave-skip-errors.
                  
@sql/log_event.cc
  skipped rbr errors when the option skip-slave-errors is set.
@sql/slave.cc
  fixed the output of for SHOW VARIABLES LIKE 'slave_skip_errors'"
@test-cases
  fixed the output of rpl.rpl_idempotency
  updated the test case rpl_skip_error

+ disable the funcs_1.charset_collation_* tests which are broken because
  of bug 38346, 40209, 40545, 40618

          on 5.0            
The server crashes on an assert in net_end_statement indicating that the
Diagnostics area wasn't set properly during execution.
This happened on a multi table DELETE operation using the IGNORE keyword.
The keyword is suppose to allow for execution to continue on a best effort
despite some non-fatal errors. Instead execution stopped and no client
response was sent which would have led to a protocol error if it hadn't been
for the assert.
This patch corrects this issue by checking for the existence of an IGNORE
option before setting an error state during row-by-row delete iteration.

updates

Attempt to execute trigger or stored function with multi-UPDATE
which used - but didn't update - a table that was also used by
the calling statement led to an error. Read-only reference to
tables used in the calling statement should be allowed.
 
This problem was caused by the fact that check for conflicting
use of tables in SP/triggers was performed in open_tables(),
and in case of multi-UPDATE we didn't know exact lock type at
this stage.

We solve the problem by moving this check to lock_tables(), so
it can be performed after exact lock types for tables used by
multi-UPDATE are determined.

  
UNION could convert fixed-point FLOAT(M,D)/DOUBLE(M,D) columns  
to FLOAT/DOUBLE when aggregating data types from the SELECT  
substatements. While there is nothing particularly wrong with  
this behavior, especially when M is greater than the hardware  
precision limits, it could be confusing in cases when all  
SELECT statements in a union have the same  
FLOAT(M,D)/DOUBLE(M,D) columns with equal precision  
specifications listed in the same position.  
  
Since the manual is quite vague on what data type should be  
returned in such cases, the bug was fixed by implementing the  
most 'expected' behavior: do not convert FLOAT(M,D)/DOUBLE(M,D)  
to anything else if all SELECT statements in a UNION have the  
same precision for that column.  

Problem: commit doesn't delete savepoints if there are no changes 
in the transaction.

Fix: delete them in such cases.

The problem is that the read and write methods of the shared
memory transport (protocol) didn't react to asynchornous close
events, which could lead to a lock up as the client would wait
(until time out) for a server response that will never come.

The solution is to also wait for close events while waiting
for I/O from or to the server.

Bug report and patch submitted by: Armin Schöffmann

The problem is that the read and write methods of the shared
memory transport (protocol) didn't react to asynchronous close
events, which could lead to a lock up as the client would wait
(until time out) for a server response that will never come.

The solution is to also wait for close events while waiting
for I/O from or to the server.

including modifications according to code review
+ backport of the fix for
  Bug 41932 funcs_1: is_collation_character_set_applicability path
                     too long for tar
  which was missing in 5.0 (just a renaming of two files)

      
When add an aliase name after NAME_CONST, the aliase name will be overwrite.
      
NAME_CONST will re-set the field's name only if there isn't an aliase in the
function fix-fields().
If there is an aliase, NAME_CONST doesn't re-set the field's name and keeps the old
name.

including modifications according to code review
+ backport of the fix for
  Bug 41932 funcs_1: is_collation_character_set_applicability path
                     too long for tar
  which was missing in 5.0 (just a renaming of two files)

            
After the table is compressed by the myisampack utility,
opening the table by the server produces valgrind warnings.
      
This happens because when we try to read a record into the buffer
we alway assume that the remaining buffer to read is always equal 
to word size(4 or 8 or 2 bytes) we read. Sometimes we have 
remaining buffer size less than word size and trying to read the 
entire word size will end up in valgrind errors.
            
Fixed by reading byte by byte when we detect the remaining buffer 
size is less than the word size.