storage/myisam/mi_dbug.c:
  Added mutex to protect open table list while traversing it

- Remove the assert in replace_where_subcondition (the patch has explanation why)

- More test result updates (the errors are the same, the difference is that "at row X" became "at row Y" due to
  queries with semi-joins producing select results in different order)

- More test result updates

- semijoin=on
- firstmatch=on
- loosescan=on

Analysis:
Equality propagation propagated the constant '7' into
args[0] of the Item_in_optimizer that stands for the
"< ANY" predicate. At the same the min/max subquery
rewrite swapped the order of the left and right operands
of the "<" predicate, but used Item_in_subselect::left_expr.

As a result, when the <ANY predicate is executed early in the
execution phase as a contant condition, instead of a constant
right (swapped) argument of the < predicate, there was a field
(t3.a). This field had no data, since the whole predicate is
considered constant, and it is evaluated before any tables are
read. Having junk in the field row buffer produced wrong result

Solution:
Fix create_swap to pick the correct Item_in_optimizer left
argument.

The problem was that merged views has its own nest_level numbering =>
when we compare nest levels we should take into considiration basis (i.e. 0 level),
if it is different then nest levels are not comparable.

- Make table elimination to actually switch itself on/off in release builds.

- The bug was caused by the following scenario:
  = a quick select is created with get_quick_select_for_ref. The quick 
    select refers to temporary (derived) table. It saves table->file, which
    refers to a ha_heap object.
  = When temp table is populated, ha_heap reaches max. size and is converted
    to a ha_myisam.  However, quick->file remains pointing to where ha_heap 
    was. 
  = Attempt to use the quick select causes crash.
- Fixed by introducing QUICK_SELECT_I::replace_handler(). Note that it will 
  not work for index_merge quick selects. Which is fine, because these
  quick selects are never created for derived tables.

- Fix the compile-time-default value of optimizer_switch printed by mysqld --help --defaults

The function Item_direct_view_ref::fix_fields erroneously did not correct
the value of the flag maybe_null when the view for which the item was
being fixed happened to be an inner table of an outer join.
 

- The problem was that the value of READ_RECORD::file was not updated when the underlying table
  was temporary and was converted from heap to myisam. Resolved by eliminating READ_RECORD::file,
  always use READ_RECORD::table->file

Honor unique/not unique when creating keys for internal tempory tables.
Added new variables to be used to limit how keys are created for internal temporary tables.


include/maria.h:
  Added maria_max_key_length() and maria_max_key_segments()
include/myisam.h:
  Added myisam_max_key_length() and myisam_max_key_segments()
mysql-test/r/mysql.result:
  Drop all used tables
mysql-test/r/subselect4.result:
  Added test case for lp:879939
mysql-test/t/mysql.test:
  Drop all used tables
mysql-test/t/subselect4.test:
  Added test case for lp:879939
sql/mysql_priv.h:
  Added internal_tmp_table_max_key_length and internal_tmp_table_max_key_segments to be used to limit how keys for derived tables are created.
sql/mysqld.cc:
  Added internal_tmp_table_max_key_length and internal_tmp_table_max_key_segments to be used to limit how keys for derived tables are created.
sql/share/errmsg.txt:
  Added new error message for internal errors
sql/sql_select.cc:
  Give error if we try to create a wrong key (this error should never happen)
  Honor unique/not unique when creating keys for internal tempory tables.
storage/maria/ha_maria.cc:
  Added change_table_ptr() to ensure that external_ref points always to the correct table.
  (Not having this caused an assert in the included test)
storage/maria/ha_maria.h:
  Added change_table_ptr() to ensure that external_ref points always to the correct table.
storage/maria/ma_check.c:
  Fixed bug in Duplicate key error printing (now row position is printed correctly)
storage/maria/ma_create.c:
  maria_max_key_length() -> _ma_max_key_length()
storage/maria/ma_info.c:
  Added extern function maria_max_key_length() to calculate the max key length based on current block size.
storage/maria/ma_open.c:
  maria_max_key_length() -> _ma_max_key_length()
storage/maria/maria_def.h:
  maria_max_key_length() -> _ma_max_key_length()
storage/myisam/ha_myisam.cc:
  Added change_table_ptr() to ensure that external_ref points always to the correct table.
  (Not having this caused an assert in the included test)
storage/myisam/ha_myisam.h:
  Added change_table_ptr() to ensure that external_ref points always to the correct table.

The function SELECT_LEX::update_used_tables first must clean up
all bitmaps to be recalculated for all tables that require it
and only after this walk through on conditions attached to the
tables to update these bitmaps.
  

- when create_ref_for_key() is constructing a ref access for
  a table that's inside a SJ-Materialization nest, it may not 
  use references to fields of tables that are unside the nest (because 
  these fields will not yet have values when ref access will be used)
  
  The check was performed in the first of create_ref_for_key's loops (the 
  one which counts how many key parts are usable) but not in the second
  (the one which actually fills the TABLE_REF structure). 

If a materialized derived table / view is empty then for this table
the value of file->ref is 0. This was not taken into account by
the function JOIN_CACHE::write_record_data. As a result a query
using an empty materialized derived tables as inner tables of outer
joins and IN subqueries in WHERE conditions could cause server crashes
when the optimizer employed join caches and duplicate elimination for
semi-joins.

Do not create KEYUSEs for a materialized view over a constant table. 

This bug happened because the function Item_cond::eval_not_null_tables
erroneously did not initialize the value of not_null_tables_cache.

The method DsMrr_impl::dsmrr_init erroneously tried to get a KEY descriptor
for key with number MAX_KEY. This caused valgrind complains.

This bug happened for the queries over multi-table mergeable views
because the bitmap TABLE::read_set of the underlying tables were not
updated after the views had been merged into the query.
Now this bitmaps are updated properly.
Also the bitmap TABLE::merge_keys now is updated in prevention of
future bugs.

The function JOIN::drop_unused_derived_keys could erroneously set
the value of REF::key to 0 for a joined materialized view/derived table
in the case when no REF access to the table was used by the query
execution plan. This could cause a crash of the server.

This bug happened due to incompleteness of the fix for bug 872735:
the occurrences of the fields in the conditions of correlated
subqueries were not taken into account when recalculating
covering keys bit maps.