installers

Rely on Universal CRT to be on every computer we install.

Improve previous patch so we do not depend on (tiny) compiler-version
dependent libraries, i.e vcruntime140.dll, and msvcp140.dll

The remaining dependency is Universal CRT, is part of Win10+ OS,
and should already be installed by Windows update on most downlevel
systems.

Do not load GetSystemTimePreciseAsFileTime() dynamically - it is available
since Windows 8. Win7 is going out of support before 10.5 reaches GA.

MDEV-19585  Assertion with S3 table and flush_tables

There was a bug in the page cache that didn't take into account that
another thread could be waiting for a page to be read by read_big_block().
Fixed by releasing all waiters in read_big_block()

There are two options when coping S3 tables with mysqldump
(there is startup option --copy_s3_tables, boolean, default no)
1) Ignore all tables with engine S3, as the data is already safe in S3 and any
computer where you restore the backup will automatically discover the S3 table.
2) Copy the table as a normal table with the following 2 changes:
- Change ENGINE=S3 to ENGINE=ARIA;
- After copy add to log 'ALTER TABLE table_name ENGINE=S3'

MDEV-19585  Assertion with S3 table and flush_tables

The limit has to be increased so that MariaDB can create system tables.
It should not have any notable impact on performance.

There should not be any notable performance differences between 1K and 4K,
especially for temporary tables. In most cases using bigger blocks is also
faster (with the possible exception of doing key reads of not fixed length
keys).

The problem was two fault:
- flush_tables() wrongly gave errors when failing to open read only tables
- backup_block_ddl() didn't properly ignores errors from flush_tables()

The test case for this will be pushed in 10.5 as the test involves
S3 tables.

os0once.h: remove as not used now

zip_pad_info_t::mutex_created: remove along with corresponding stuff

zip_pad_info_t::mutex: make member value instead of a pointer

dict_table_t::stats_latch_created: remove along with related stuff

dict_table_t::stats_latch: make value member, not pointer. And always lock this
for simplicity, even to stats cloned table.

based on the work of Sergey Vojtovich

Get rid of os_once.

The error occured because aria_copy_to_s3() function tried to copy .frm file
of partition, but partition does not have it's own .frm file. The same is true
for aria_rename_s3().

To fix this issue the new parameter was added to those two functions to specify
if .frm file must be copied or not. The parameter is set to 'false' for
partitions.

Also there was other issue with EXCHANGE PARTITION. Briefly, there is the
following sequence of operations(see  exchange_name_with_ddl_log() for details):
1) rename swap table to temporary table,
2) rename partition to swap table,
3) rename temporary table to partition.

On step (1) .frm file is renamed too. On step (2) the swap table does not
have .frm file, as partition does not have it. On step (3) partition will have
.frm file, because it will be renamed from temporary table. All of this causes
error on different stages of the table access. To fix it, .frm is not touched
at all for s3 during EXCHANGE PARTITION operation. This is implemented in
ha_s3::rename_table() by additional checking of
current_thd->lex->alter_info.partition_flags(see also ALTER_PARTITION_EXCHANGE
in sql_yacc.yy).

MDEV-19049 Server crashes in check_duplicate_long_entry_key, ASAN stack-buffer-overflow in Field_blob::get_key_image

Long Unique keys should always be last unique key.

Limit lines to ~16K

The bug occured when the optimizer decided to use a rowid filter built
by a range index scan to access an InnoDB table with generated clustered
index.
When a table is accessed by a secondary index Idx employing a rowid filter the
the value of pk contained in the found index tuple is checked against the
filter. A call of the handler function position is supposed to put the
pk value into the handler::ref buffer. However for generated clustered
primary keys it did not happened. The patch fixes this problem.

Make Field::is_equal() const and return bool as it's a naturally fitting
type for it. Also it's agrument was narrowed to Column_definition.

InnoDB can change type of some columns by itself. InnoDB-specific code used to
reside in Field_xxx:is_equal() methods. Now engine-specific stuff was
moved to a virtual methods of handler::can_convert{string,varstring,blob,geom}.
These methods are called by Field::can_be_converted_by_engine() which is a
double dispatch pattern.

Some InnoDB-specific code still resides in compare_keys_but_name(). It should
be moved from here someday to handler::compare_key_parts(...) or similar.

IS_EQUAL_WITH_REINTERPRET_COMPATIBLE_CHARSET
IS_EQUAL_WITH_REINTERPRET_COMPATIBLE_CHARSET_BUT_COLLATE: both was removed

IS_EQUAL_NO, IS_EQUAL_YES are not needed now and should be removed
along with deprecated handler::check_if_incompatible_data().

HA_EXTENDED_TYPES_CONVERSION: was removed as such logic is not needed now by
server code.

ALTER_COLUMN_EQUAL_PACK_LENGTH: was renamed to a more generic
ALTER_COLUMN_TYPE_CHANGE_BY_ENGINE

Patch is about two cases:
1) On some collate changes it's possible to rebuild only secondary indexes
2) For non-indexed columns collate can be changed INSTANTly

Implemented mostly in Field_{string,varstring,blob}::is_equal().
Make this method return how exactly collationa differs.
This information is later used by fill_alter_inplace_info() to pass
correct info to engine.

Introduced the convert_to_printable_required_length to return the correct length(taking into
consideration of dots in the case of error messages).