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