The Microsoft compiler only allows function attributes before the
function signature, not after it.

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.

References to global symbols prevent InnoDB from being built as a
dynamic plugin on Windows.

Refer to CHARSET_INFO::number, because that is what InnoDB is already
persistently storing in its data dictionary.

btr_node_ptr_max_size(): Treat CHAR(0) from SQL as a special case.
The InnoDB internal SQL parser maps the type "CHAR" to DATA_VARCHAR,
but MariaDB does allow CHAR(0) with an empty value, and does enforce
the length limitation.

keyinfo->name is a LEX_CSTRING

also, fix the location comment (that applied to ext_key_part_map)

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.

ha_innobase::prepare_inplace_alter_table(): check max column length for every
index in a table, not just added in this particular ALTER TABLE with ADD INDEX ones.

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.