Raise version number after cloning 5.5.40
Bug #19471516 SERVER CRASHES WHEN EXECUTING ALTER TABLE ADD FOREIGN KEY

Problem:

We maintain two rb trees in each dict_table_t.  The foreign_rbt must be in
sync with foreign_list.  The referenced_rbt must be in sync with
referenced_list. There is one function which checks this consistency and it
failed, resulting in an assert failure.

The root cause of the problem was identified that the search order was 
lost in the referenced_rbt.  This is because while renaming the table,
we didn't not refresh this referenced_rbt.

Solution:

When a foreign key is renamed, we must delete and re-insert into both
foreign_rbt and referenced_rbt.  

rb#6412 approved by Jimmy.
Rename enterprise repo packages to commercial
Changing the copyright headers a bit to be complaint with the standards
Update copyright text.
      Bug#19145712 USER AFTER FREE / DOUBLE FREE ISSUE
      
      Problem: A corrupted header length in FORMAT_DESCRIPTION_LOG_EVENT
      can cause server to crash.
      Analysis: FORMAT_DESCRIPTION_EVENT will be considered invalid if
      header len is too small (i.e. below OLD_HEADER_LEN).
      
      Format_description_log_event:: Format_description_log_event(...)
      {
        ...
        if ((common_header_len=buf[ST_COMMON_HEADER_LEN_OFFSET]) < OLD_HEADER_LEN)
          DBUG_VOID_RETURN; /* sanity check */
        ...
        post_header_len= my_memdup(...)
      }
      
      In that case Format_description_log_event constructor will return early,
      without allocating any memory for post_header_len. Thence this variable is
      left uninitialized and making server to crash when server is trying
      to free the uninitialized value.
      
      Fix: When Format_description_log_event constructor returns early, assign
      NULL to post_header_len.
Bug #19361402 - ADD --MANUAL-LLDB OPTION TO MYSQL-TEST-RUN.PL, contributed
Bug #19361317 - --MANUAL-GDB EFFECTIVELY TRUNCATES OPTION FILE ARGS AT FIRST SEMICOLON
removed WL7219: Audit Log Filtering from mysql-5.5.
Bug#18790730 - CROSS-DATABASE FOREIGN KEY WITHOUT PERMISSIONS
               CHECK.

Analysis:
----------
Issue here is, while creating or altering the InnoDB table,
if the foreign key defined on the table references a parent
table on which the user has no access privileges then the
table is created without reporting any error. 

Currently the privilege level REFERENCES_ACL is unused
and is not used for access evaluation while creating the
table with a foreign key constraint or adding the foreign
key constraint to a table. But when no privileges are granted
to user then also access evaluation on parent table is ignored.

Fix:
---------
For DMLs, irrelevant of the fact, support does not want any
changes to avoid permission checks on every operation.

So, as a fix, added a function "check_fk_parent_table_access" 
to check whether any of the SELECT_ACL, INSERT_ACL, UDPATE_ACL,
DELETE_ACL or REFERENCE_ACL privileges are granted for user
at table level. If none of them is granted then error is reported.
This function is called during the table creation and alter 
operation.
Bug #18964545 ADD MTR SUPPORT FOR DEBUGGING WITH LLDB
Bug#19070633 - POSSIBLE ACCESS TO FREED MEMORY IN IS_FREE_LOCK()
                AND IS_USED_LOCK().

Analysis:
-----------
In functions Item_func_is_free_lock::val_int() and 
Item_func_is_used_lock::val_int(), for the specified user lock
name, pointer to its "User_level_lock" object is obtained from hash
"hash_user_locks". Mutex "LOCK_user_locks" is acquired for this
and released immediately. And we are accessing members of
User_level_lock after releasing the mutex. If same user lock is
deleted(released) from concurrent thread then accessing members
results in invalid(freed) memory access issue.

Deleting of user lock is also protected from the mutex
"LOCK_user_locks". Since this mutex is released in "val_int" 
functions mentioned above, delete operation proceeds while concurrent
thread tries to access its members.

With the test case, valgrind reports invalid read issues in val_int
functions.

Fix:
-----------
To fix this issue, in "val_int" function of classes
"Item_func_is_free_lock" and "Item_func_is_used_lock", now releasing
mutex "LOCK_user_locks" after accessing User_level_lock members.
Bug #17852083 PRINT A WARNING WHEN DDL HAS AN ERROR IN INNODB_STRICT_MODE = 1

Problem:

Creation of a table fails when innodb_strict_mode is enabled, but the same
table is created without any warning when innodb_strict_mode is enabled.

Solution:

If creation of a table fails with an error when innodb_strict_mode is
enabled, it must issue a warning when innodb_strict_mode is disabled.

rb#6723 approved by Krunal.
Bug #19306524 FAILING ASSERTION WITH TEMP TABLE FOR A PROCEDURE CALLED
FROM A FUNCTION

Scenario:

In a stored procedure, CREATE TABLE statement is not allowed.  But an
exception is provided for CREATE TEMPORARY TABLE.  We can create a temporary
table in a stored procedure.

Let there be two stored functions f1 and f2 and two stored procedures p1 and
p2.  Their properties are as follows:

. stored function f1() calls stored procedure p1().
. stored function f2() calls stored procedure p2().
. stored procedure p1() creates temporary table t1.
. stored procedure p2() does DML on t1.

Consider the following situation:

1.  Autocommit mode is on. 
2.  select f1()
3.  select f2()

Step 2:  In this step, t1 would be created via p1().  A table level transaction
lock would have been taken.  The ::external_lock() would not have been called
on this table.  At the end of step 2, because of autocommit mode on, this table
level lock will be released.

Step 3:  When we execute DML on table t1 via p2() we have two problems:

Problem 1:

The function ha_innobase::external_lock() would have been called but since
it is a select query no table level locks would have been taken.  Hence the
following assert will fail:

ut_ad(lock_table_has(thr_get_trx(thr), index->table, LOCK_IX));

Solution:

The solution would be to identify this situation and take a table level lock
and use the proper lock type prebuilt->select_lock_type = LOCK_X for DML
operations.

Problem 2:

Another problem is that in step 3, ha_innobase::open() is never called on
the table t1.  

Solution:

The solution would be to identify this situation and call re-init the handler
of table t1.

rb#6429 approved by Krunal.
Merge from mysql-5.5.40-release
Bug #15868071 	USING SET GLOBAL SQL_LOG_BIN SHOULD NOT BE ALLOWED

Normally, SET SESSION SQL_LOG_BIN is used by DBAs to run a
non-conflicting command locally only, ensuring it does not
get replicated.
Setting GLOBAL SQL_LOG_BIN would not require all sessions to
disconnect. When SQL_LOG_BIN is changed globally, it does not
immediately take effect for any sessions. It takes effect by
becoming the session-level default inherited at the start of
each new session, and this setting is kept and cached for the
duration of that session. Setting it intentionally is unlikely
to have a useful effect under any circumstance; setting it
unintentionally, such as while intending to use SET [SESSION]
is potentially disastrous. Accidentally using SET GLOBAL
SQL_LOG_BIN will not show an immediate effect to the user,
instead not having the desired session-level effect, and thus
causing other potential problems with local-only maintenance
being binlogged and executed on slaves; And transactions from
new sessions (after SQL_LOG_BIN is changed globally) are not
binlogged and replicated, which would result in irrecoverable
or difficult data loss.
This is the regular GLOBAL variables way to work, but in
replication context it does not look right on a working server
(with connected sessions) 'set global sql_log_bin' and none of
that connections is affected. Unexperienced DBA after noticing
that the command did "nothing" will change the session var and
most probably won't unset the global var, causing new sessions
to not be binlog.
Setting GLOBAL SQL_LOG_BIN allows DBA to stop binlogging on all
new sessions, which can be used to make a server "replication
read-only" without restarting the server. But this has such big
requirements, stop all existing connections, that it is more
likely to make a mess, it is too risky to allow the GLOBAL variable.

The statement 'SET GLOBAL SQL_LOG_BIN=N' will produce an error
in 5.5, 5.6 and 5.7. Reading the GLOBAL SQL_LOG_BIN will produce
a deprecation warning in 5.7.
Bug #18964545 - ADD MTR SUPPORT FOR DEBUGGING WITH LLDB revert
Bug#19695101 UPGRADE YASSL TO 2.3.5