dict_index_add_to_cache_w_vcol(): merge with dict_index_add_to_cache()

In commit d1e6b0bc
some code was supposed to be modified, but instead
it got duplicated. Remove the duplicated copy.

* use compile_time_assert instead of DBUG_ASSERT

* don't use thd->clear_error(), because
  * the error was already consumed by the error handler, so there is
     nothing to clear
  * it's dangerous to clear errors indiscriminately, if the error came
    from outside of read_statistics_for_tables() it must not be cleared

mysql_insert() first opens all affected tables (which implicitly
starts a transaction in InnoDB), then stat tables.
A failure to open a stat table caused open_tables() to abort
the current stmt transaction (trans_rollback_stmt()). So, from the
server point of view the following ha_write_row()-s happened outside
of a transactions, and the server didn't bother to commit them.

The server has a mechanism to prevent a transaction being
unexpectedly committed or rolled back in the middle of a statement -
if an operation takes place _in a sub-statement_ it cannot change
the transaction state. Operations on stat tables are exactly that -
they are not allowed to change a transaction state. Put them in
a sub-statement to make sure they don't.

following Fedora recommendations (see %systemd_post macro in FC29)
let's do `systemctl preset` on the first installation of the server

This reverts commit 396313d3.

Apply the changes to InnoDB and XtraDB that had been
inadvertently skipped in the merge
commit ae476868

That merge failure sabotaged part of MDEV-20127:
>Revert a problematic auto_increment_increment 'fix' from 2014.
>This involves replacing the MDEV-8827 fix and in 10.1,
>removing some WSREP instrumentation.

The code changes were re-merged manually by executing the following:

 # Get the parent of the problematic merge.
git checkout ae476868^
 # Perform the merge again.
git merge ae476868^2
 # Get the conflict resolution from that merge.
git checkout ae476868 .
 # Note: Any changes to these files were removed (empty diff)!
git diff HEAD storage/{innobase,xtradb}/handler/ha_innodb.cc
 # Apply the code changes:
git diff cf403934^2..MERGE_HEAD \
storage/{innobase,xtradb}/handler/ha_innodb.cc|
patch -p1

Basicaly it's an uninitialized read. 165 is 0xa5 which comes from TRASH_ALLOC()

Fix by calling a class ctor which initializes problematic
TMP_TABLE_PARAM::force_copy_fields field

In debug build, whenever MEMORY table instance gets closed it performs
consistency check without protection. It may cause server crash if
executed concurrently with DML.

Moved consistency check to ha_heap::external_lock(F_UNLCK), so that it
is protected by THR_LOCK.

Changes to be committed:
	modified:   mysql-test/suite/galera/r/MW-369.result
	modified:   mysql-test/suite/galera/r/MW-402.result
	modified:   mysql-test/suite/galera/r/galera#500.result
	modified:   mysql-test/suite/galera/r/galera_gcs_fragment.result
	modified:   mysql-test/suite/galera/r/mysql-wsrep#332.result

Lock wait can happen on secondary index when doing FK checks for wsrep.
We should just return error to upper layer and applier will retry
operation when needed.

ut_strlcpy(): Replace with the standard function strncpy().

ut_strlcpy_rev(): Define in the same compilation unit where
the only caller resides. Avoid unnecessary definition
in non-debug builds.

mem_heap_dup(): Avoid mem_heap_alloc() and memcpy() of data=NULL, len=0.

trx_undo_report_insert_virtual(), trx_undo_page_report_insert(),
trx_undo_page_report_modify(): Avoid memcpy(ptr, NULL, 0).

dfield_data_is_binary_equal(): Correctly handle data=NULL, len=0.

This clean-up was motivated by WITH_UBSAN, and no bug related to this
was observed in the wild. It should be noted that undefined behaviour
such as memcpy(ptr, NULL, 0) could allow compilers to perform unsafe
optimizations, like it was the case in
commit fc168c3a (MDEV-15587).

Ignore GetDiskFreeSpace() errors in os_file_get_status_win32
The call is only used to calculate filesystem block size, and this in
turn is only  shown in information_schema.sys_tablespaces.FS_BLOCK_SIZE.
There is no other use of this field, it does not affect any Innodb
functionality

Ever since MariaDB 10.0 (and MySQL 5.6.8), the innodb_log_file_size
and innodb_log_files_in_group can be changed between server restarts,
and the redo log files will be resized on server startup if needed.

use the correct table for evaluating virtual columns in the
InnoDB ALTER TABLE.

switch to definer privileges when populating I_S tables