WL#7076: Backporting wl6715 to support both formats in 5.5, 5.6, 5.7

         Backporting wl6715 to mysql-5.5
Raise version number after cloning 5.5.33
Raise version number after cloning 5.1.71
Empty version change upmerge
Bug #14017206 WITH CONSISTENT SNAPSHOT DOES NOT WORK WITH ISOLATION LEVEL
SERIALIZABLE

Problem:

The documentation claims that WITH CONSISTENT SNAPSHOT will work for both
REPEATABLE READ and SERIALIZABLE isolation levels.  But it will work only
for REPEATABLE READ isolation level.  Also, the clause WITH CONSISTENT
SNAPSHOT is silently ignored when it is not applicable to the given isolation
level.  

Solution:

Generate a warning when the clause WITH CONSISTENT SNAPSHOT is ignored.

rb#2797 approved by Kevin.

Note: Support team wanted to push this to 5.5+.
Fix Bug #16710923 - FALSE REPORTS OF DB_FOREIGN_EXCEED_MAX_CASCADE
                  
rb://2582 approved by Inaam
Fix bug 1188168 (Fake changes assertion fail in
row_ins_clust_index_entry_by_modify() |
btr_store_big_rec_extern_fields ()).

The issue is caused that fake changes, while normally skipping the
write of externally-stored columns, failed to so for one path in
row_ins_index_entry_low().  Adjust accordingly and add a regression
testcase.
Bug #17035577 - MTR V1 FAILS TO START SERVER MTR_VERSION=1 PERL MYSQL-TEST-RUN.PL 1ST
upmerge bug 17035577 5.1 => 5.5
BUG#15844882: MYSQLDUMP FROM 5.5 FAILS WITH AN ERROR WHEN TRYING
              TO DUMP DATA FROM MYSQL-5.6

Analysis
--------
Dumping mysql-5.6 data using mysql-5.1/mysql-5.5 'myqldump'
utility fails with a syntax error.

Server system variable 'sql_quote_show_create' which quotes the
identifiers is set in the mysqldump utility. The mysldump utility
of mysql-5.1/mysql-5.5 uses deprecated syntax 'SET OPTION' to set
the 'sql_quote_show_create' option. The support for the syntax is
removed in mysql-5.6. Hence syntax error is reported while taking
the dump.

Fix:
---
Changed the 'mysqldump' code to use the syntax
'SET SQL_QUOTE_SHOW_CREATE' to set the 'sql_quote_show_create'
option. That syntax is supported on mysql-5.1, mysql-5.5 and
mysql-5.6.

NOTE: I have not added an mtr test case since it is difficult
to simulate the condition. Also the syntax may not be further
simplified in the future.
BUG#15844882: MYSQLDUMP FROM 5.5 FAILS WITH AN ERROR WHEN TRYING
              TO DUMP DATA FROM MYSQL-5.6 

Merge from mysql-5.1 to mysql-5.5.
BUG#16295518 - SYS_VARS.RPL_INIT_SLAVE_FUNC IS FAILING ON MYSQL-5.1 
BUG#12535301- SYS_VARS.RPL_INIT_SLAVE_FUNC MISMATCHES IN DAILY-5.5 

Problem:
sys_vars.rpl_init_slave_func test was not recorded after
the last edit. It was disabled on 5.1 after seeing failures
due to the above reason.
No old failures as this suite never ran with pb2 on 5.1

Fix:
Added assert condition after wait for checks.
Recorded test and enabled it.
BUG#12535301- SYS_VARS.RPL_INIT_SLAVE_FUNC MISMATCHES IN DAILY-5.5

Problem:
sys_vars.rpl_init_slave_func test was failing sporadically 
on 5.5+.

Fix:
Added assert condition after wait for checks.
Recorded test and enabled it.
Bug#16865959 - PLEASE BACKPORT BUG 14749800.

Since log_throttle is not available in 5.5. Logging of
error message for failure of thread to create new connection
in "create_thread_to_handle_connection" is not backported.

Since, function "my_plugin_log_message" is not available in 
5.5 version and since there is incompatibility between
sql_print_XXX function compiled with g++ and alog files with
gcc to use sql_print_error, changes related to audit log
plugin is not backported.
Fix for Bug#16614004 CRASH AFTER READING FREED MEMORY AFTER DOING DDL IN STORED ROUTINE
Inside a loop in a stored procedure, we create a partitioned
table. The CREATE statement is thus treated as a prepared statement:
it is prepared once, and then executed by each iteration. Thus its Lex
is reused many times. This Lex contains a part_info member, which
describes how the partitions should be laid out, including the
partitioning function. Each execution of the CREATE does this, in
open_table_from_share ():

    tmp= mysql_unpack_partition(thd, share->partition_info_str,
                                share->partition_info_str_len,
                                outparam, is_create_table,
                                share->default_part_db_type,
                                &work_part_info_used);
 ...
      tmp= fix_partition_func(thd, outparam, is_create_table);
The first line calls init_lex_with_single_table() which creates
a TABLE_LIST, necessary for the "field fixing" which will be
done by the second line; this is how it is created:
  if ((!(table_ident= new Table_ident(thd,
                                      table->s->db,
                                      table->s->table_name, TRUE))) ||
      (!(table_list= select_lex->add_table_to_list(thd,
                                                   table_ident,
                                                   NULL,
                                                   0))))
    return TRUE;
it is allocated in the execution memory root.
Then the partitioning function ("id", stored in Lex -> part_info)
is fixed, which calls Item_ident:: fix_fields (), which resolves
"id" to the table_list above, and stores in the item's
cached_table a pointer to this table_list. 
The table is created, later it is dropped by another statement,
then we execute again the prepared CREATE. This reuses the Lex,
thus also its part_info, thus also the item representing the
partitioning function (part_info is cloned but it's a shallow
cloning); CREATE wants to fix the item again (which is
normal, every execution fixes items again), fix_fields ()
sees that the cached_table pointer is set and picks up the
pointed table_list. But this last object does not exist
anymore (it was allocated in the execution memory root of
the previous execution, so it has been freed), so we access
invalid memory.
The solution: when creating the table_list, mark that it
cannot be cached.
Bug #17076737 DUPLICATE CONSTRAINTS DISPLAYED WHEN NAME INCLUDES "_IBFK_"

Problem:

When the user specified foreign key name contains "_ibfk_", InnoDB wrongly
tries to rename it. 

Solution:

When a table is renamed, all its associated foreign keys will also be renamed,
only if the foreign key names are automatically generated.  If the foreign key
names are given by the user, even if it has _ibfk_ in it, it must not be
renamed.

rb#2935 approved by Jimmy, Krunal and Satya
Merge from mysql-5.1 to mysql-5.5