This reverts commit dacd1794.

- Add SLEEP() calls to the testcase to make it really test that the
  time doesn't change.
- Always use .frm file creation time as a creation timestamp (attempts
  to re-use older create_time when the table DDL changes are not good
  because then create_time will change after server restart)
- Use the same method names as the upstream patch does
- Use std::atomic for m_update_time

wsrep_init_provider_status_variables(): Always set wsrep_inited
to ensure that the memory will be freed.

The initial patch was provided by Julius Goryavsky.

Variant#5 of the patch:
- take creation date from the .frm file, like InnoDB does
- Update_time is in-memory only (like in InnoDB).

innobase_drop_foreign_try(): Don't evict and reload the dict_foreign_t
during instant ALTER TABLE if the FOREIGN KEY constraint is being
dropped.

The MDEV-19630 fix (commit 07b1a26c)
was incomplete, because it did not cover a case where the
FOREIGN KEY constraint is being dropped.

MDEV-18244 Server crashes in ha_innobase::update_thd / ... / ha_partition::update_next_auto_inc_val.

Partition table with the AUTO_INCREMENT column we ahve to check if the
max value is properly loaded. So we need to open all tables in INSERT
PARTITION statement if necessary. Also we need to check if some
tables are pruned away and not count the max autoincrement in this case.

Variant#5 of the patch:
- take creation date from the .frm file, like InnoDB does
- Update_time is in-memory only (like in InnoDB).

Temporarily revert the patch

doubles in scientific notation with a big integer part.

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

MDEV-19516 mysql_secure_installation doesn't set password_last_changed while setting password for root

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