If the first component of a ref key happened to be a constant appeared
after constant row substitution then no store_key element should be
created for such a component. Yet create_ref_for_key() erroneously could
create such an element that caused construction of invalid ref keys and
wrong results for some joins.

Bug #952372: Server crashes on 2nd execution of PS in find_field_in_tables with semijoin+materialization

The problem was that convert_subq_to_jtbm() attached the semi-join
TABLE_LIST object into the wrong list: they used to attach it to the
end of parent_lex->leaf_tables.head()->next_local->...->next_local.
This was apparently inccorect, as one can construct an example where
JTBM nest is attached to a table that is inside some mergeable VIEW, which
breaks (causes crash) for name resolution on the subsequent statement
re-execution.

Solution: Attach to the "right" list. The "wording" was copied from
st_select_lex::handle_derived.

Make the slave options --replicate-* dynamic variables so that these
options can be changed dynamically while the server is running,
which enables users to modify replication filtering rules without
having to stop and restart the server.

This is accomplished by just requiring that the slave threads are
stopped when these options are set dynamically. Since filtering
rules are only used by the SQL slave thread, setting them while the
thread is not running avoids the need for locking.

If in the where clause of the a query some comparison conditions on the
field under a MIN/MAX aggregate function contained constants whose sizes
exceeded the size of the field then the query could return a wrong result
when the optimizer had chosen to apply the MIN/MAX optimization.

With such conditions the MIN/MAX optimization still could be applied, yet
it would require a more thorough analysis of the keys built to find
the value of MIN/MAX aggregate functions with index look-ups.

The current patch just prohibits using the MIN/MAX optimization in this
situation.

Do not call, directly or indirectly, SQL_SELECT::test_quick_select()
for derived materialized tables / views when optimizing joins referring
to these tables / views to get cost estimates of materialization.

The current code does not create B-tree indexes for materialized
derived tables / views. So now it's not possible to get any estimates
for ranges conditions over the results of the materialization.

The function mysql_derived_create() must take into account the fact
that array of the KEY structures specifying the keys over a derived
table / view may be moved after the optimization phase if the
derived table / view is materialized.

The file uses external variables defined in another (C++) source file. Since
MSVC mangles variables and not only functions, either variables in question
should be extern "C", or sql_logger should be made C++ for link to succeed.