MDEV-3942 FROM_DAYS(<timestamp column>) returns different result in MariaDB comparing to MySQL: NULL vs 0000-00-00

fixed a regression, introduced while fixing MDEV-456

from a MERGE view.

The problem was in the lost ability to be null for the table of a left join if it
is a view/derived table.

It hapenned because setup_table_map(), was called earlier then we merged
the view or derived.

Fixed by propagating new maybe_null flag during Item::update_used_tables().

Change in join_outer.test and join_outer_jcl6.test appeared because
IS NULL reported no used tables (i.e. constant) for argument which could not be
NULL and new maybe_null flag was propagated for IS NULL argument (Item_field)
because table the Item_field belonged to changed its maybe_null status.

MDEV-3928: Assertion `example' failed in Item_cache::is_expensive_processor with a 2-level IN subquery

Analysis:
The following call stack shows that it is possible to set Item_cache::value_cached, and the relevant value
without setting Item_cache::example.

#0 Item_cache_temporal::store_packed at item.cc:8395
#1 get_datetime_value at item_cmpfunc.cc:915
#2 resolve_const_item at item.cc:7987
#3 propagate_cond_constants at sql_select.cc:12264
#4 propagate_cond_constants at sql_select.cc:12227
#5 optimize_cond at sql_select.cc:13026
#6 JOIN::optimize at sql_select.cc:1016
#7 st_select_lex::optimize_unflattened_subqueries at sql_lex.cc:3161
#8 JOIN::optimize_unflattened_subqueries at opt_subselect.cc:4880
#9 JOIN::optimize at sql_select.cc:1554

The fix is to set Item_cache_temporal::example even when the value is
set directly by Item_cache_temporal::store_packed. This makes the
Item_cache_temporal object consistent.

Fixed algorithm of detecting of first real table in view/subquery-in-the-FROM-clase.

If the setting of system variables does not allow to use join buffer
for a join query with GROUP BY <f1,...> / ORDER BY <f1,...> then
filesort is not needed if the first joined table is scanned in
the order compatible with order specified by the list <f1,...>.

Fix some problems in the TC_LOG_MMAP commit processing, which could
lead to assertions in some cases.

Problems are mostly reproducible in MariaDB 10.0 with asynchroneous
commit checkpoints, but most of the problems were present in earlier
versions also.

Adjust unstable test case.

Properly drop all unused keys.
Patch by Igor Babaev.

MDEV-736 LP:1004615 - Unexpected warnings "Encountered illegal value '' when converting to DECIMAL" on a query with aggregate functions and GROUP BY

fix: don't call field->val_decimal() if the field->is_null()
because the buffer at field->ptr might not hold a valid decimal value

sql/item_sum.cc:
  do not call field->val_decimal() if the field->is_null()
storage/maria/ma_blockrec.c:
  cleanup
storage/maria/ma_rrnd.c:
  cleanup
strings/decimal.c:
  typo

followup fixes for MySQL Bug #13889741: HANDLE_FATAL_SIGNAL IN _DB_ENTER_ | HANDLE_FATAL_SIGNAL IN STRNLEN

Take into account that length of strings passed down to this function can be up to FN_REFLEN+1 bytes. including terminating zero.
The overwrite was caused by incomplete fix to MySQL Bug # 44834

If triggers are used for an insert/update/delete statement than the values of
all virtual columns must be computed as any of them may be used by the triggers.

add a test case for MySQL Bug #13889741: HANDLE_FATAL_SIGNAL IN _DB_ENTER_ | HANDLE_FATAL_SIGNAL IN STRNLEN

  
The problem is that memory alocated by copy_andor_structure() well be freed,
but if level of SELECT_LEX it will be excluded (in case of merge derived tables and view)
then sl->where/having will not be updated here but still can be accessed (so it will be access to freed memory).

(patch by Sanja)

Made information_schema_all_engines stable by adding "sorted_result".

If, when executing a query with ORDER BY col LIMIT n, the optimizer chose
an index-merge scan to access the table containing col while there existed
an index defined over col then optimizer did not consider the possibility
of using an alternative range scan by this index to avoid filesort. This
could cause a performance degradation if the optimizer flag index_merge was
set up to 'on'.