Checksum implementations contain optimizations for calculating
checksums of larger blocks of memory.

This optimization calls my_checksum on a larger block of memory
rather than calling on multiple adjacent memory as its going though
the table columns for each table row.

- Change some static variables to dynamic to ensure that we don't do any memory
  allocations before server starts or stops
- Print more memory information on SIGHUP. Fixed output.
- Write out if memory was lost if run with --debug-at-exit
- Fixed wrong #ifdef in sql_cache.cc

- Avoid some realloc() during startup
- Ensure that file_key_management_plugin frees it's memory early, even if
  it's linked statically.
- Fixed compiler warnings from unused variables and missing destructors
- Fixed wrong indentation

MariaDB 10.1.x 32-bit binaries.

Problem was the fact that tablespace size was incorrectly
rounded to next extent size (1M).

wrong mutex usage from safe_mutex.
Ensure that LOCK_status is always taken before LOCK_thread_count

Problem was that cost_group_min_max() could not handle if group by was optimized away.

This appears to break some installation, and it did not do anything
useful anyway.

change buffer not empty

Fix: Allow not empty change buffer when innodb_force_recovery >= 5
and output only a warning to error log.

Note: Before using force recovery you should always take backup
of your database.

When the specification of a WITH table referred to a view
that used a based table with the same name as the WITH table
the server went into an infinite loop because it erroneously
resolved the reference to the base table as the reference to
the WITH table.

With tables used in a view cannot be searched for beyond the
scope the view.

When the specification of a WITH table referred to a view
that used a based table with the same name as the WITH table
the server went into an infinite loop because it erroneously
resolved the reference to the base table as the reference to
the WITH table.

With tables used in a view cannot be searched for beyond the
scope the view.

The issues themselves were fixed as part of MDEV-8646

When join output is just one row, we still need to compute window
function values for it. We could skip invoking filesort for it,
but it doesn't seem to be worth it to do such optimization.

Make Frame_range_current_row_bottom to take into account partition bounds.

Other partition bounds that could potentially hit the end of partition are
Frame_range_n_bottom, Frame_n_rows_following, Frame_unbounded_following,
and they all had end-of-partition protection.

To simplify the code, factored out end-of-partition checks into
class Partition_read_cursor.

This bug revealed a serious problem: if the same partition list
was used in two window specifications then the temporary table created
to calculate window functions contained fields for two identical
partitions. This problem was fixed as well.

Don't hold a separate pointer as args[0] changes during fix_fields /
split_sum_func.

When ordering by a column and partitioning by another, we must reset the
peer_tracker for dense_rank, regardless if the value for the order
column changes or not.

Example:
select a, b, dense_rank() over (partition by b order by a)
a  |  b  |  dense_rank
----------------------
1  | p1  |           1
2  | p1  |           2
2  | p2  |           1   // Here, without this fix we returned 0.
2  | p2  |           2   // And 1 here.

The bug was caused by a weird behaviour in test_if_group_changed, not
returning true when testing for the first time after initializing
the Cached_item list.

Implement the "DISTINCT must not be converted into GROUP BY when window
functions are present" part.

n=0 in "ROWS 0 PRECEDING" is valid, add handling for it:
- Adjust the assert
- Bottom bound of 'ROW 0 PRECEDING' is actually looking at the current
  row, that is, it needs to process partition's first row directly in
  Frame_n_rows_preceding::next_partition().
- Added testcases

Window functions need to have their own column in the work (temp) table,
like aggregate functions do.
They don't need val_int() -> val_int_result() conversion though, so they
should be wrapped with Item_direct_ref, not Item_aggregate_ref.