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

In some cases, MariaDB 10.0 could write a master.info file that was read
incorrectly by 10.1 and could cause server to fail to start after an upgrade.

(If writing a new master.info file that is shorter than the old, extra
junk may remain at the end of the file. This is handled properly in
10.1 with an END_MARKER line, but this line is not written by
10.0. The fix here is to make 10.1 robust at reading the master.info
files written by 10.0).

Fix several things around reading master.info and read_mi_key_from_file():

 - read_mi_key_from_file() did not distinguish between a line with and
   without an eqals '=' sign.

 - If a line was empty, read_mi_key_from_file() would incorrectly return
   the key from the previous call.

 - An extra using_gtid=X line left-over by MariaDB 10.0 might incorrectly
   be read and overwrite the correct value.

 - Fix incorrect usage of strncmp() which should be strcmp().

 - Add test cases.