Updated Code for Bug#16235828 and Bug#16298542
Bug#16068056 INNODB CALLS BUF_VALIDATE() TOO OFTEN WITH UNIV_DEBUG

Approved by: Marko Makela (patch in bug report)

Reduce the number of debug buf_validate() calls
merge from 5.5
re commit
Bug#16434398 TRANSPOSED VARIABLES IN READ-ONLY MODE ERROR

Fix error log text.

Approved by Jimmy Yang on IM.
NULL Merge for release 5.1.69
Null Merge for release 5.1.69.
Merge from mysql-5.5 to mysql-5.6
Bug #16133801 UNEXPLAINABLE INNODB UNIQUE INDEX LOCKS ON DELETE +
INSERT WITH SAME VALUES

Problem:

When a transaction is in READ COMMITTED isolation level, gap locks are still
taken in the secondary index, when row is inserted.  This happens when the
secondary index is scanned for duplicate.  

The function row_ins_scan_sec_index_for_duplicate() always calls the 
function row_ins_set_shared_rec_lock() with LOCK_ORDINARY irrespective of
the transaction isolation level.

Solution:

The function row_ins_scan_sec_index_for_duplicate() calls the 
function row_ins_set_shared_rec_lock() with LOCK_ORDINARY or 
LOCK_REC_NOT_GAP based on the transaction isolation level.

rb://2035 approved by Krunal and Marko
Null merge from mysql-5.5 to mysql-5.6
Bug#16272562 - WRONG RESULTS: SELECT DISTINCT ... XOR ..

Problem:-
The range optimizer used to set up incorrect ranges for queries with XOR. 
This resulted in missing rows

Analysis:-
The range optimizer set up incorrect range for query like this
select ... where any_field XOR 'any_constant_value'

Solution:
The fix is to not use range access for the XOR operation by treating 
'a XOR b' as always true. Thus, for conditions like

WHERE <something> AND (a XOR b)

range access can still be used on <something>.

It is possible to optimize XORs better by treating them as normal ORs and 
let condition filtering remove rows that are 'true XOR true'. 
This will be fixed by WL#5800.
Bug #16043216 DROP DATABASE: ASSERTION: !TABLE->CAN_BE_EVICTED
|| TABLE->IBD_FILE_MISSING

Problem 1:

When a drop dabase is done the SQL layer do the following steps:

1.  Drop each table individually from InnoDB.
2.  Drop database from InnoDB

But, if the frm file of a particular table is missing, step (1)
will not happen.  Because of this, in step (2), the can_be_evicted
flag of the table will be TRUE.   In step (2), we assert that
can_be_evicted flag of the table will be FALSE.

Solution:

Under certain situations, the frm file of a table can be missing.
During drop database, if the can_be_evicted flag is TRUE, then
issue a warning, but proceed with the operation.  There is no need
to assert.

Problem 2:

When an ALTER TABLE command is issued against a table that contains
an FTS index to add a foreign key constraint, and if this alter fails,
then proper cleanup was not happening.  The FTS index tables that was
created was not cleaned up, but were left as orphans.  Because of this
a subsequent drop database statement was failing.  

Proper cleanup of the FTS index tables was not happening because the
necessary FTS index information was not loaded when the failure happened.
The error handling code didn't have access to the FTS index information.

Solution:

The FTS index information is loaded before attempting to add the foreign
key constraint.  This ensures that proper cleanup is done when alter
table fails to add a foreign key constraint.

rb#2119 approved by Marko and Jimmy.
Added fix for Bug#16445097
Added fix for Bug#16445097
Making part.partition_debug_inndob experimental since the failure frequency is very high on PB2
Fix Bug #16413976 - CRASH IN INNOBASE_INIT_FOREIGN 

rb://2103 approved by Marko
Bug#16169063: SECURITY CONCERN BECAUSE OF INSUFFICIENT LOGGING

PROBLEM: If multiple statements are sent by a single
         request then only the last statement was
         getting logged. An attacker can bypass the
         audit log just by sending two comsecutive
         statements in one request.

SOLUTION: Each statements from a single request are
          logged.
BUG#16169063: merge from mysql-5.5 to mysql-5.6.
merge 5.5 => 5.6