MDEV-4556 Server crashes in SEL_ARG::rb_insert with index_merge+index_merge_sort_union, FORCE INDEX
- merge_same_index_scans() may put the same SEL_ARG tree in multiple result plans.
  make it call incr_refs() on the SEL_ARG trees that it does key_or() on, because 
  key_or(sel_arg_tree_1, sel_arg_tree_2) call may invalidate SEL_ARG trees pointed 
  by sel_arg_tree_1 and sel_arg_tree_2.
    

In function ‘void* memset(void*, int, size_t)’,
    inlined from ‘void Lifo_buffer::set_buffer_space(uchar*, uchar*)’ at sql_lifo_buffer.h:70:5,
    inlined from ‘int DsMrr_impl::dsmrr_init(handler*, RANGE_SEQ_IF*, void*, uint, uint, HANDLER_BUFFER*)’ at multi_range_read.cc:895:62:
/usr/include/i386-linux-gnu/bits/string3.h:82:32: error: call to ‘__warn_memset_zero_len’ declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters [-Werror]

It was intentional that the buffer is set to zero length there.

(gdb) p dbug_print_table_row(table)
  $33 = "SUBQUERY2_t1(col_int_key,col_varchar_nokey)=(7,c)"

- Item_direct_view_ref didn't clear its pointer to item_equal in ::cleanup.
- Some Item_direct_view_ref objects have statement lifetime (i.e. they
  survive across multiple EXECUTE commands). Item_equal objects live only for
  the duration of one EXECUTE. This caused Item_direct_view_ref to have a stale pointer,
  which could cause all sorts of effects. (In this bug's testcase it was pointing to
  the wrong Item_equal, causing wrong query result)
- Fixed by doing what Item_field::cleanup() does - don't keep item_equal pointer value.
- There is no testcase because the only testcase I've got is highly fragile (e.g. the
  bug will not show up if @@datadir is of the wrong length).

Fixed so the MYSQL_TYPE_GEOMETRY is treated as BLOB.

The result is EMPTY for a buffer(line, -1), but we still
need one FALSE operation to be stored in the condition.
And we actually add it but forgot to alloc memory to store it.

- The problem was that JOIN::prepare() tried to set TABLE::maybe_null
  for a table in join. Non-merged semi-join tables 1) are present as 
  join's base tables on second EXECUTE, but 2) do not yet have a TABLE 
  object.
  Worked around the problem by putting mixed_implicit_grouping into JOIN
  object, and then passing it to JTBM tables in setup_jtbm_semi_joins().

(just to have the test in the tree when we merge the upstream fix)

Don't ignore the error from st_select_lex_unit::optimize()

as it was supposed to be in bug#11747970, don't fake an error.
(this kill can be useful for other bugs too)

(mainly by backporting 5.5. changes)

mysql-test/suite/maria/t/distinct.test:
  Remove the test that requires SSL. One test case for a bug is enough.
sql/scheduler.cc:
  make it the same as in 5.5
storage/innodb_plugin/row/row0mysql.c:
  make it the same as in 5.5
storage/innodb_plugin/row/row0sel.c:
  make it the same as in 5.5
storage/xtradb/row/row0mysql.c:
  make it the same as in 5.5
storage/xtradb/row/row0sel.c:
  make it the same as in 5.5

fix the NAME_CONST check to only allow literals, negated literals, and literals with
the explicit collation.

The method Item_field::update_table_bitmaps() should not try
to mark the bit for a self-referencing virtual column.

- Let cleanup_empty_jtbm_semi_joins() walk into semi-join nests.

The field JOIN::select_lex->where should be updated after the call
of remove_eq_conds() in the function make_join_statistics(). This
matters for subselects.

Set of JOIN_TYPE_OUTER made only once to avoid interference with optimization joins which made only once per query.

on server shutdown after SELECT with CONVERT_TZ

It's wrong to return my_empty_string from val_str().
Removing my_empty_string. Using make_empty_result() instead.

Assertion `mon > 0 && mon < 13' failed.'

MDEV-5337: Wrong result in mariadb 5.5.32 with ORDER BY + LIMIT when 
index_condition_pushdown=on
- in test_if_skip_sort_order(), correct the condition under which
  we have the code that restores the previously pushed index condition.

The crash happened because Item_func_monthname was derived from
Item_func_month, so Item_func_monthname::is_null() did not work fine.
Backporting a change from 5.5: Item_func_monthname is now derived from
Item_str_func.

- convert_subq_to_sj() must connect child select's tables into 
  parent select's TABLE_LIST::next_local chain.  
- The problem was that it took child's leaf_tables.head() which
  is different. This could cause certain tables (in this bug's case,
  child select's non-merged semi-join) not to be present in 
  TABLE_LIST::next_local chain.  Which would cause non-merged semi-join
  not to be initialized in setup_tables(), which would lead to 
  NULL pointer dereference.

THD::thd->activate_stmt_arena_if_needed() should be used to temporary activating statement arena instead of direct usage of THD::set_n_backup_active_arena() because possible such scenario:
  1) func1 saves current arena and activates copy1 of statement arena
  2) func2 saves copy1 of statement arena setup by func1 and activates copy2
  3) some changes made for copy 2
  4) func2 stores changed copy2 back to statenet arena and activates copy1
  5) func1 store unchanged copy1 back to statemnt arena (rewrite changed copy 2 so changes become lost) and activates arena which was before.

THD::thd->activate_stmt_arena_if_needed() should be used to temporary activating statement arena instead of direct usage of THD::set_n_backup_active_arena() because possible such scenario:
  1) func1 saves current arena and activates copy1 of statement arena
  2) func2 saves copy1 of statement arena setup by func1 and activates copy2
  3) some changes made for copy 2
  4) func2 stores changed copy2 back to statenet arena and activates copy1
  5) func1 store unchanged copy1 back to statemnt arena (rewrite changed copy 2 so changes become lost) and activates arena which was before.

update_used_tables() should be called after handling derived tables in any case.