cherry-picked 7454f1c5 from 10.1

When CHANGE MASTER was executed as a PS, its attributes were wrongly
getting reset toward the end of PREPARE. As a result, the subsequent
executions had no effect. Fixed by making sure that the CHANGE MASTER
attributes are preserved during the lifetime of the PS.

* OSX (mysqlimport freeing unallocated memory)
* Windows (didn't compile MSI)
* fulltest2 (innodb crashes in --embedded --big)

make_cond_for_info_schema() does preserve outer fields

Substitute into transformed subselects original left expression and than register its change in case it was substituted.

MDEV-7565: Server crash with Signal 6 (part 2)

followup test suite and its fix.

Problem was in rewriting left expression which had 2 references on it. Solved with making subselect reference main.

Item_in_optimized can have not Item_in_subselect reference in left part so type casting with no check is dangerous.

Item::cols() should be checked after Item::fix_fields().

Preparation of subselect moved earlier (before checks which needs it prepared).

MDEV-8845: Table disappear after modifying FK

Added test case.

Fixed incorrect access to freed memory.

Made no_rows_in_result()/restore_to_before_no_rows_in_result() not looking
annecessary deep with walk() method.

The patch was pushed into 10.0, but it needs to be applied to 5.5 as well

The test restarts the server and expects that the feedback plugin
will send a report on shutdown, and will write about it in the error
log. But the server is only given 10 sec to shut down properly,
which is not always enough.
Added a parameter to restart_mysqld.inc, and set it to a bigger
value in feedback_plugin_send

The culprit is the feedback_plugin_load test, which is run both separately
and from inside feedback_plugin_send.test. The test queries I_S.FEEDBACK,
and every time it does, 'FEEDBACK used' value is increased.
Fixed by checking that the value is increased instead of recording the actual
value in the result file.

The test would take really long if it was run without --mem.
Fixed by adding --innodb-flush-log-at-trx-commit=2

The real problem is that when innodb.xa_recovery test intentionally
crashes the server, system tables can be opened and marked as crashed,
and the next test in line gets blamed for the error which appears
in the error log.
Fixed by flushing the tables before crashing the server

(cherry picked from commit 7f9941eab55ed672bfcccd382dafbdbcfdc75aaa)

INITIAL STARTUP

Updated yassl to yassl-2.3.7e

(cherry picked from commit 6e21c8c04b922bdb60b6a7c174709d2e1bdd3618)

Backport of upstream patch. revno: 5696

MDEV-8663: IF Statement returns multiple values erroneously (or Assertion `!null_value' failed in Item::send(Protocol*, String*))

Postreview addons by Bar

Fix: keeping contract: NULL value mean NULL pointer in val_str and val_deciman.

              FIELD_ITERATOR_TABLE::END_OF_FIELDS

Note: This a backport of the patch for bug#19894987
      to MySQL-5.5

               PROBLEMS

Description:- Server variable "--lower_case_tables_names"
when set to "0" on windows platform which does not support
case sensitive file operations leads to problems. A warning
message is printed in the error log while starting the
server with "--lower_case_tables_names=0". Also according to
the documentation, seting "lower_case_tables_names" to "0"
on a case-insensitive filesystem might lead to index
corruption.

Analysis:- The problem reported in the bug is:-
Creating an INNODB table 'a' and executing a query, "INSERT
INTO a SELECT a FROM A;" on a server started with
"--lower_case_tables_names=0" and running on a
case-insensitive filesystem leads innodb to flat spin.
Optimizer thinks that "a" and "A" are two different tables
as the variable "lower_case_table_names" is set to "0". As a
result, optimizer comes up with a plan which does not need a
temporary table. If the same table is used in select and
insert, a temporary table is needed. This incorrect
optimizer plan leads to infinite insertions.

Fix:- If the server is started with
"--lower_case_tables_names" set to 0 on a case-insensitive
filesystem, an error, "The server option
'lower_case_table_names'is configured to use case sensitive
table names but the data directory is on a case-insensitive
file system which is an unsupported combination. Please
consider either using a case sensitive file system for your
data directory or switching to a case-insensitive table name
mode.", is printed in the server error log and the server
exits.

Syncs "official" and our own Docker images

DESCRIPTION
===========
Inability of mysql LOAD XML command to handle empty XML
tags i.e. <row><tag/></row>. Also the behaviour is wrong
and (different than above) when there is a space in empty
tag i.e. <row><tag /></row>

ANALYSIS
========
In read_xml() the case where we encounter a close tag ('/')
we're decreasing the 'level' blindly which is wrong.
Actually when its an without-space-empty-tag (succeeding
char is '>'), we need to skip the decrement. In other words
whenever we hit a close tag ('/'), decrease the 'level'
only when (i) It's not an (without space) empty tag i.e.
<tag/> or, (ii) It is of format <row col="val" .../>

FIX
===
The switch case for '/' is modified. We've removed the
blind decrement of 'level'. We do it only when its not an
without-space-empty-tag. Also we are setting 'in_tag' to
false to let program know that we're done reading current
tag (required in the case of format <row col="val" .../>)

              VIEW


It appears that the code refactoring done as part of the
patch for the MySQL BUG#11749859 fixed this issue. This
issue is not reproducible on MySQL 5.5+ versions now.
As part of this patch, the test file "mysqldump.test" has
been updated to remove the comment which was referring to
the bug and also the line which suppresses the warning.

Analysis :
==========
During JOIN::prepare of sub-query which creates the
derived tables we call setup_procedure. Here we call
fix_fields for parameters of procedure clause. Calling
setup_procedure at this point may cause issue. If
sub-query is one of parameter being fixed it might
lead to complicated dependencies on derived tables
being prepared.

SOLUTION :
==========
In 5.6 with WL#6242, we have made procedure clause
parameters can only be NUM, so sub-queries are not
allowed as parameters. So in 5.5 we can block
sub-queries in procedure clause parameters.
This eliminates above conflicting dependencies.

PROBLEM

Whenever we insert in unique secondary index we take shared
locks on all possible duplicate record present in the table.
But while during a replace on the unique secondary index ,
we take exclusive and locks on the all duplicate record.
When the records are deleted, they are first delete marked
and later purged by the purge thread. While purging the
record we call the lock_update_delete() which in turn calls
lock_rec_inherit_to_gap() to inherit locks of the deleted
records. In repeatable read mode we inherit all the locks
from the record to the next record  but in the read commited
mode we skip inherting them as gap type locks. We make a
exception here if the lock on the records is  in shared mode
,we assume that it is set during insert for unique secondary
index and needs to be inherited to stop constraint violation.
We didnt handle the case when exclusive locks are set during
replace, we skip inheriting locks of these records and hence
causing constraint violation.

FIX

While inheriting the locks,check whether the transaction is
allowed to do TRX_DUP_REPLACE/TRX_DUP_IGNORE, if true
inherit the locks.

[ Revewied by Jimmy #rb9709]

The root cause is that x86 has a stronger memory model than the ARM
processors. And the GCC builtins didn't issue the correct fences when
setting/unsetting the lock word. In particular during the mutex release.

The solution is rewriting atomic TAS operations: replace '__sync_' by
'__atomic_' if possible.
Reviewed-by: Sunny Bains      <sunny.bains@oracle.com>
Reviewed-by: Bin Su           <bin.x.su@oracle.com>
Reviewed-by: Debarun Banerjee <debarun.banerjee@oracle.com>
Reviewed-by: Krunal Bauskar   <krunal.bauskar@oracle.com>
RB: 9782
RB: 9665
RB: 9783

send_result_set_metadata

Analysis
--------
Cursor inside trigger accessing NEW/OLD row leads server exit.

The reason for the bug was that implementation of function
create_tmp_table() was not considering Item::TRIGGER_FIELD_ITEM
as possible alternative for type of class being instantiated.
This was resulting in a mismatch between a number of columns
in result list and temp table definition. This mismatch leads
to the failure of assertion
DBUG_ASSERT(send_result_set_metadata.elements == item_list.elements)
in the method Materialized_cursor::send_result_set_metadata
in debug mode.

Fix:
---
Added code to consider Item::TRIGGER_FIELD_ITEM as valid
type while creating fields.

(cherry picked from commit 1bfe5f724bc4c24da635f632247e7d263aa53970)

Conflicts:
	mysql-test/lib/mtr_cases.pm

(cherry picked from commit 3eb933e0eb55f962404a04741767177e12a9885f)

Conflicts:
	mysql-test/mysql-test-run.pl