This is fixing a regression that was introduced in MDEV-15562
commit 0e5a4ac2.

On rollback of UPDATE or DELETE of a ROW_FORMAT=COMPRESSED table,
page_zip_write_trx_id_and_roll_ptr() was accessing
offsets=offsets_ after offsets_ went out of scope.

btr_cur_pessimistic_insert(): Convert the metadata field of the metadata
record into BLOB before inserting, just like btr_cur_optimistic_insert()
does.

MDEV-17968 Error 174 "Fatal error during initialization of handler" from storage engine Aria upon DELETE from partitioned table

The correct title is:
MDEV-17972 Assertion `is_valid_value_slow()' failed in Datetime::Datetime

MDEV-17968 Error 174 "Fatal error during initialization of handler" from storage engine Aria upon DELETE from partitioned table

--echo # MDEV-17979 Assertion `0' failed in Item::val_native upon SELECT with timestamp, NULLIF, GROUP BY
--echo #

Implement User_table_json.
Fix scripts to use mysql.global_priv.
Fix tests.

Introduce User_table_tabular(mysql.user) and User_table_json(mysql.global_priv).
The latter is not implemented.
Automatic fallback to the old implementation works.

Results change because privilege tables are opened in a different
order now.

prepare TABLE_LIST in a loop and just before opening
don't store TABLE_LIST inside Grant_table_base.

move all backward compatibility related code into User_table,
the caller should not know or care anymore.

Other tables (Db_table, etc) are *not* refactored.

For consistency with other updates, setting a default role
no longer errors out when the mysql.user table is too old.

because the first byte of a _binary hash_ can be 0x00 too.

This fixes main.connect test on centos73-ppc64

SIGHUP causes debug info in the error log and reload of
logs/privileges/tables/etc. The server should only do it when
a user intentionally sends SUGHUP, not when a parent terminal gets
disconnected or something.

In particular, not ignoring kernel SIGHUP causes FLUSH PRIVILEGES
at some random point during non-systemd Debian upgrades (Debian
restarts mysqld, debian-start script runs mysql_upgrade in the background,
postinit script ends and kernel sends SIGHUP to all background processes
it has started). And during mysql_upgrade privilege tables aren't
necessarily ready to be reloaded.

Service added to handle json.

We failed to reset the dict_table_t::persistent_autoinc after
instantly dropping an AUTO_INCREMENT column, causing a bogus
call to row_parse_int() on a subsequent insert.

Current implementation is conflicting. If `UNICODE` is defined, `FormatMessage()` will be `FormatMessageW()`, and variable `win_errormsg` with type `char` can not be passed to it, which should be changed to `TCHAR` instead. Since we don't use UNICODE here, we can use `FormatMessageA()` directly to avoid conversion error.
```
my_global.h(1092): error C2664: 'DWORD FormatMessageW(D
WORD,LPCVOID,DWORD,DWORD,LPWSTR,DWORD,va_list *)' : cannot convert argument 5 from 'char [2048]' to 'LPWSTR'
```

The fix of MDEV-17793 was updating SYS_INDEXES.TABLE_ID in order
to make the table invisible to purge (lazily delete old undo log
records).

By design of InnoDB, an update of TABLE_ID cannot be rolled back,
because the rollback would effectively drop all indexes of the table
due to the internal 'trigger' on SYS_INDEXES modifications.

So, we revert the code change of MDEV-17793 and instead fix
MDEV-17793 in a different way: by tweaking the undo log parsing
during purge.

The MDEV-17793 bug scenario is that a table becomes empty and
a third instant ALTER TABLE is executed before purge processes
the undo log record for the second instant ALTER TABLE. After
this point, when purge sees the record, the table could have
a mismatching number of rows.

The test case works with this alternative fix. But what about
a scenario where a fourth instant ALTER TABLE arrives before
purge processes the second one? Could anything bad happen?

Purge is only doing two things: First, free any BLOBs that
were affected by the update record, and then, reset the
DB_TRX_ID,DB_ROLL_PTR if a matching record is found.
For the hidden metadata record, the only BLOB that we update
is the hidden metadata BLOB that was introduced by MDEV-15562.
Any other BLOBs (for the initial default values of instantly
added columns) are never updated.

So, in our scenario, the metadata BLOB that was created by
the first instant ALTER TABLE (if it involved dropping or
permuting columns) would be freed by purge when it is processing
the undo record of the second ALTER TABLE. The BLOB value that
was written by the second ALTER TABLE should be freed when
the table is emptied. This is currently not done: MDEV-17383
should fix that. There is no possibility of double-free, because
purge would only free old values of BLOBs.

What about MVCC and other callers of trx_undo_update_rec_get_update()?
The answer is simple: they should never be accessing the hidden
metadata record in the first place.

dict_table_t::reassign_id(): Remove.

btr_cur_pessimistic_delete(): Clarify a comment.

row_mysql_table_id_reassign(), row_discard_tablespace_for_mysql():
Add comments explaining that the operation cannot be rolled back.

trx_undo_update_rec_get_update(): Avoid out-of-bounds access when
parsing a metadata record. Avoid unnecessary memory allocation when
filtering out fields from the update vector.

When update finishes, MDL_context::release_transactional_locks() first
releases MDL_STATEMENT locks (MDL_BACKUP_DML and MDL_BACKUP_TRANS_DML
in this particular cases), which allows FTWRL connection to proceed.
Then MDL_TRANSACTION locks get released (MDL_SHARED_WRITE in this case).
metadata_lock_info query may sporadically hit this gap and observe
these otherwise unexpected locks.

After MDEV-17772 table existence check is performed much earlier, so
create_table_select_before_check_if_exists debug sync point is not
reachable when table exists.

Moved debug sync point to appropriate place.

The result is updated here because by changing the defaults for use_stat_tables
EITs statistcs are providing more accurate statistics than INNODB statistics.

row_undo_ins_remove_clust_rec(): When rolling back the insert
of a metadata record, also reset the root page state within the
same mini-transaction.

dict_table_t::rollback_instant(): Do not allow index->n_core_fields
to be larger than index->n_fields. This logic exists in the 10.3
branch but was incorrectly removed as part of MDEV-15562 in 10.4.0.

mariabackup.lock_ddl_per_table was broken, after MDEV-17772 got fixed.
Fix removes MDL waiter killer, it is is not needed anymore.

This regression was introduced in MDEV-11369 instant ADD COLUMN.

prepare_inplace_alter_table_dict(): Avoid dereferencing ctx->new_table
after row_create_table_for_mysql() returns a failure code, because
it will have freed the memory.

There was a race condition in the error handling of ALTER TABLE when
the table contains FULLTEXT INDEX.

During the error handling of an erroneous ALTER TABLE statement,
when InnoDB would drop the internally created tables for FULLTEXT INDEX,
it could happen that one of the hidden tables was being concurrently
accessed by a background thread. Because of this, InnoDB would defer
the drop operation to the background.

However, related to MDEV-13564 backup-safe TRUNCATE TABLE and its
prerequisite MDEV-14585, we had to make the background drop table queue
crash-safe by renaming the table to a temporary name before enqueueing it.
This renaming was introduced in a follow-up of the MDEV-13407 fix.
As part of this rename operation, we were unnecessarily parsing the
current SQL statement, because the same rename operation could also be
executed as part of ALTER TABLE via ha_innobase::rename_table().

If an ALTER TABLE statement was being refused due to incorrectly formed
FOREIGN KEY constraint, then it could happen that the renaming of the hidden
internal tables for FULLTEXT INDEX could also fail, triggering a host of
error log messages, and causing a subsequent table-rebuilding ALTER TABLE
operation to fail due to the tablespace already existing.

innobase_rename_table(), row_rename_table_for_mysql(): Add the parameter
use_fk for suppressing the parsing of FOREIGN KEY constraints. It
will only be passed as use_fk=true by ha_innobase::rename_table(),
which can be invoked as part of ALTER TABLE...ALGORITHM=COPY.

Removing the unused THD* parameter.

MDEV-17772 - 3 way lock : ALTER, MDL, BACKUP STAGE BLOCK_DDL

While waiting for a (potentially long) RO transaction or SELECT, DDL and
LOCK TABLES ... WRITE hold protection against FTWRL and BACKUP STAGE.

This effectively makes FTWRL/BACKUP STAGE indirectly wait for this RO
transaction or SELECT to finish. Which is not great, as otherwise we
could do something useful meanwhile.

With this patch BACKUP lock is attempted to be acquired after TABLE/SCHEMA
locks. If this attempt fails, TABLE/SCHEMA locks gets released and we
start waiting for BACKUP lock. When wait finishes, BACKUP lock is released
(to avoid deadlocks) and we attempt to acquire all locks once again.

Other changes:
- Take MDL lock before testing if table exists as part of
  CREATE TABLE ... IF EXISTS.  This change was an effect of changes in
  lock_table_name and removes an inconsistency where one could get
  different error messages from CREATE TABLE .. IF EXISTS depending on
  active mdl locks.
  One effect of this change is that we don't binary log CREATE TABLE IF
  EXISTS if the table exists.  This was done because old code was sometimes
  behaving inconsistenly (it was logged some time and not other times)
  and sending the query to the slave could make the slave even more
  inconsistent as there is not guarantee that the new table will have
  the same definition as the old table on the master.

Part of MDEV-5336 Implement LOCK FOR BACKUP

- Changed check of Global_only_lock to also include BACKUP lock.
- We store latest MDL_BACKUP_DDL lock in thd->mdl_backup_ticket to be able
  to downgrade lock during copy_data_between_tables()

Part of MDEV-5336 Implement LOCK FOR BACKUP

- Added new locks to MDL_BACKUP for all stages of backup locks and
  a new MDL lock needed for backup stages.
- Renamed MDL_BACKUP_STMT to MDL_BACKUP_DDL
- flush_tables() takes a new parameter that decides what should be flushed.
- InnoDB, Aria (transactional tables with checksums), Blackhole, Federated
  and Federatedx tables are marked to be safe for online backup. We are
  using MDL_BACKUP_TRANS_DML instead of MDL_BACKUP_DML locks for these
  which allows any DML's to proceed for these tables during the whole
  backup process until BACKUP STAGE COMMIT which will block the final
  commit.

- Call delete_statistics_tables() after lock_table_names in drop tables.
  This avoids a deadlock issue with FTWRL and future backup locks.
- Added some missing clear_error()
- Ensure we don't clear error caused by the caller
- Updated function comments

- Re-numbered enum_table_category to make some tests easier
- Moved TABLE_CATEGORY_INFORMATION to be first CATEGORY of virtual tables
- Don't take MDL locks for not updateable table category's

Part of MDEV-5336 Implement LOCK FOR BACKUP

FLUSH TABLE table_names have changed slighty as we are now opening
tables before taking the MDL lock. The difference is that FLUSH TABLE
table_name will now be blocked by a table that is waiting for FTWRL.
There should not be any new deadlocks as part of this change.

The end result is still better in most cases as FTWRL is now only
waiting for write statements to end, not for read only statements and
it's not flushing tables in use from the table cache.

Share will be needed to be able to determine if table supports online
backup. Appropriate metadata lock type in BACKUP namespace will be
acquired basing on this information.

Also made pending global read lock request to be preferred victim of MDL
deadlock detector. This allows us to hide some non-fatal deadlocks and
make FTWRL less likely to break concurrent queries.

Part of MDEV-5336 Implement LOCK FOR BACKUP

Other things:
- Added printing of MDL locks to DBUG.