The function add_ref_to_table_cond missed updating the value of
join_tab->pre_idx_push_select_cond after having updated the value
of join_tab->select->pre_idx_push_select_cond.

- Do not push index condition if we're using a triggered ref access.

update test results

The bug happened because in some cases the function JOIN::exec
did not save the value of TABLE::pre_idx_push_select_cond in
TABLE::select->pre_idx_push_select_cond for the sort table.

Noticed and fixed a bug in the function make_cond_remainder
that builds the remainder condition after extraction of an index
pushdown condition from the where condition. The code
erroneously assumed that the function make_cond_for_table left
the value of ICP_COND_USES_INDEX_ONLY in sub-condition markers.
Adjusted many result files from the regression test suite
after this fix .

The call of the virtual function cancel_pushed_idx_cond in the code of
the function test_if_skip_sort_order was misplaced when backporting the
fix for bug 58816.

Better error message if --log-bin is used without --log-bin-index

mysql-test/lib/v1/mysql-test-run.pl:
  Fixed that test doesn't abort if 'var' points to a deleted directory (common case when using --mem)
sql/mysqld.cc:
  Better error message if --log-bin is used without --log-bin-index

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.

Fixed a bug in select_describe.
Adjusted results for affected test cases.

- 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.

(Failed to reproduce the bug in mariadb-5.3).

The bug was fixed by the patches for LP bugs 668644,702322 that
were applied earlier to the mariadb-5.3 code.

The bug was fixed by the patch for LP bug 694092 that was
applied earlier to the mariadb-5.3 code.

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