The function SELECT_LEX::update_used_tables should process all
ORDER BY lists in any subselect of a union.

MDEV-5113 Wrong result (extra row) and valgrind warnings in Item_maxmin_subselect::any_value on 2nd execution of PS with SELECT subquery

When setting Item_func_not_all::test_sum_item or Item_func_not_all::test_sub_item,
reset the other one to NULL - they can never be set both. When a PS is reexecuted,
different executions might be optimized differently and a wrong test_su*_item
might stay set from the previous execution.

MDEV-5153: Server crashes in Item_ref::fix_fields on 2nd execution of PS with LEFT JOIN and MERGE view or SELECT SQ

1. Transformation of row IN subquery made the same as single value.
2. replace_where_subcondition() made working on several layers of OR/AND because it called on expression before fix_fields().

Singular Item_equal support added.

The problem was that during constant table substitution Item_equal become containing only one constant which was not supported internally.

The loop in the binary search in remove_status_vars() was
incorrectly implemented and could continue infinitely in some cases.
Rewrote the binary search code.

  
  There was 2 problems:
  1) coping/moving of the same type (usually casting) as sizeof() (solved in different ways depends on the cause);
  2) using 'const' in SSL_CTX::getVerifyCallback() which return object (not reference) and so copy of the object will be created and 'const' has no sens.

Analysis:
st_select_lex_unit::prepare() computes can_skip_order_by as TRUE.
As a result join->prepare() gets called with order == NULL, and
doesn't do name resolution for the inner ORDER clause. Due to this
the prepare phase doesn't detect that the query references non-exiting
function and field.
  
Later join->optimize() calls update_used_tables() for a non-resolved
Item_field, which understandably has no Field object. This call results
in a crash.

Solution:
Resolve unnecessary ORDER BY clauses to detect if they reference non-exising
objects. Then remove such clauses from the JOIN object.

MDEV-5143: update of a joined table with a nested subquery with a syntax error crashes mysqld with signal 11

Added check of SELECT_LEX::handle_derived() result.

MDEV-5034:Wrong result on LEFT JOIN with a SELECT SQ or a merge view, UNION in IN subquery

Make reset null_row same as it was set in evaluate_null_complemented_join_record().

The problem was that view firlds detect null_row by not-yet-reset table.

The patch for bug mdev-5105 incorrectly counted conditions in nested joins.

Objects of the classes Item_func_isnull and Item_func_isnotnull
must have the flag sargable set to TRUE.
Set the value of the flag sargable only in constructors of the 
classes inherited from Item_int_func.

The bug caused a memory overwrite in the function update_ref_and_keys()
It happened due to a wrong value of SELECT_LEX::cond_count. This value
historically was calculated by the fix_fields method. Now the logic of
calling this method became too complicated and, as a result, this value
is calculated not always correctly.
The patch changes the way how and when  the values of SELECT_LEX::cond_count
and of SELECT_LEX::between_count are calculated. The new code does it just at
the beginning of update_ref_and_keys().
 

For aggregated fields from views/derived tables the possible adjustment
of thd->lex->in_sum_func->max_arg_level in the function Item_field::fix_fields
must be done before we leave the function.

Apparently in a general case a short-cut for the distinct optimization
is invalid if join buffers are used to join tables after the tables whose
values are to selected.

Other fix of maybe_null problem and revert of revno: 3608 "MDEV-3873 & MDEV-3876 & MDEV-3912 : Wrong result (extra rows) with ALL subquery from a MERGE view."

mtr can crash occasionally.
This happens when mtr sends to a child mtr process (or vice-versa) a packet,
that gets truncated or, perhaps, split in two.
Then the other side cannot deserialize it and fails as above.

Adding tests only.

The problem was earlier fixed by 
MDEV-4724 Some temporal functions do not preserve microseconds 

Adding test cases from the bug report only.

The problem was earlier fixed by:
MDEV-4863 COALESCE(time_or_datetime) returns wrong results in numeric context

modified:
  mysql-test/r/func_time.result
  mysql-test/t/func_time.test

Adding a test case only.

The problem was fixed by:

  MDEV-4724 Some temporal functions do not preserve microseconds

modified:
  mysql-test/r/func_time.result
  mysql-test/t/func_time.test

The patch for mdev-4355 had a defect: the cached values for bitmaps of
used tables were not updated when processing degenerate OR formulas.

Removed unneeded set of TABLE_LIST::skip_temporary flag.

- Provide a special execution path for cleanup of degenerate 
  non-merged semi-join children of degenerate selects.

The fix for bug mdev-4971 not always correctly set the pointers to
inherited multiple equalities in objects of the Item_equal class. 

The function propagate_new_equalities() did not updated properly
the references to inherited multiple equalities.

When a non-nullable datetime field is used under an IS NULL predicate
of the WHERE condition in a query with outer joins the remove_eq_conds
function should check whether this field belongs to an inner table
of any outer join that can be, in a general case, a nested outer join.

When in function remove_eq_conds() a sub-formula of the processed condition
is replaced for another formula we should ensure that in the resulting
formula AND/OR levels must alternate.