MDEV-18372: Minor MDEV-17973-related merge issue to 10.3

Use the same data type 'ulong' to avoid type mismatch on Windows
and on 32-bit systems.

FIXME: The correct data type should probably be 64-bit.

When innobase_allocate_row_for_vcol() returns true (for failure),
it may already have invoked mem_heap_create(). However, some callers
would fail to invoke mem_heap_free().

pcre needs symbols from pcreposix
(but this is only an issue when linking with system static libraries)

Problem:
========
Server fails to notify the engine by not setting the ADD_PK_INDEX and
DROP_PK_INDEX When there is a
 i) Change in candidate for primary key.
 ii) New candidate for primary key.

Fix:
====
Server sets the ADD_PK_INDEX and DROP_PK_INDEX while doing alter for the
above problematic case.

I missed this in commit 9a7281a7

PROBLEM
-------

1. We are inserting a base column entry which causes an invalid value
   by the function provided to generate virtual column,but we go ahead
   and insert this due to ignore keyword.
2. We then delete this record, making this record delete marked in innodb.
   If we try to insert another record with the same pk as the deleted
   record and if the rec is not purged ,then we try to undelete mark this
   record and try to build a update vector with previous and updated value
   and while calculating the value of virtual column we get error from
   server that we cannot calculate this from base column.
   Innodb assumes that innobase_get_computed_value() Should always return
   a valid value for the base column present in the row. The failure of
   this call was not handled ,so we were crashing.

FIX

Thanks to commit 2614a0ab
before MDEV-5800, no version of MariaDB is affected by this bug
that was fixed in MySQL 5.7.25.

10.1 part: SHOW CREATE USER didn't show the password, if plugin was set,
but authentication_string was not

remove tests that rely on specific execution order

remove tests that rely on specific execution order

MDEV-17421: mtr does not restart the server whose parameters were changed

           32 bit int

Row-based slave applier could not parse correctly the table id when
the value exceeded the max of 32 bit unsigned int.
The reason turns out in that the being parsed value placeholder
was sized as 4 bytes.

The type is fixed to ulonglong.

Additionally the patch works around Rows_log_event::m_table_id 4 bytes
size on 32 bits platforms. In case of last_table_id value overflows
the 4 byte max, there won't be the zero value for m_table_id generated
and the first wrapped-around value is one, this is thanks to excluding
UINT_MAX32 + 1 from TABLE_SHARE::table_map_id.

Rename it because it caused parser warning whenever --backup was used.

dict_sys_get_size(): Replace the time-consuming loop with
a crude estimate that can be computed without holding any mutex.

Even before dict_sys->size was removed in MDEV-13325,
not all memory allocations by the InnoDB data dictionary cache
were being accounted for. One example is foreign key constraints.
Another example is virtual column metadata, starting with 10.2.

on startup innodb is checking whether files "ib_logfileN"
(for N from 1 to 100) exist, and whether they're readable.
A non-existent file aborted the scan.
A directory instead of a file made InnoDB to fail.

Now it treats "directory exists" as "file doesn't exist".

When InnoDB is invoking posix_fallocate() to extend data files, it
was missing a call to fsync() to update the file system metadata.
If file system recovery is needed, the file size could be incorrect.

When the setting innodb_flush_method=O_DIRECT_NO_FSYNC
that was introduced in MariaDB 10.0.11 (and MySQL 5.6) is enabled,
InnoDB would wrongly skip fsync() after extending files.

Furthermore, the merge commit d8b45b0c
inadvertently removed XtraDB error checking for posix_fallocate()
which this fix is restoring.

fil_flush(): Add the parameter bool metadata=false to request that
fil_buffering_disabled() be ignored.

fil_extend_space_to_desired_size(): Invoke fil_flush() with the
extra parameter. After successful posix_fallocate(), invoke
os_file_flush(). Note: The bookkeeping for fil_flush() would not be
updated the posix_fallocate() code path, so the "redundant"
fil_flush() should be a no-op.

MDEV-17835: Remove wsrep-sst-method=xtrabackup

thd_destructor_proxy() may miss abort signal if innobase_end() is running
concurrently, which causes server hang in pthread_join() on shutdown.

The problem was that aborting wasn't protected by mutex:
proxy thr: while (!myvar->abort)
end thr: running->abort = 1;
end thr: mysql_cond_broadcast(...);
proxy thr: mysql_cond_wait(...); // nobody to awake it
end thr: pthread_join(...); // waits for proxy thr

Also made main.mysqld_option_err reentrant.

The second line of changes related to replacing xtrabackup with
mariabackup:

1) All unnecessary references to xtrabackup are removed from
the documentation, from some comments, from the control files
that are used to prepare the packages.

2) Made corrections of the tests from the galera_3nodes suite
that mentioned xtrabackup or the old (associated with xtrabackup)
version of innobackupex.

3) Fixed flaws in the galera_3nodes mtr suite control scripts,
because of which they could not work with mariabackup.

4) Fixed numerous bugs in the SST scripts and in the mtr test
files (galera_3nodes mtr suite) that prevented the use of Galera
with IPv6 addresses.

5) Fixed flaws in tests for rsync and mysqldump (for galera_3nodes
mtr tests suite). These tests were not performed successfully without
these fixes.

https://jira.mariadb.org/browse/MDEV-17835

increase to 1M

MDEV-17973: Don't overwrite xtrabackup-v2/mariabackup SST logs by def…

MDEV-11369 (instant ADD COLUMN) introduced a regression in the case the
leftmost leaf page of the clustered index is empty except for the
hidden metadata record.

btr_pcur_store_position(): If the only record in the leftmost leaf page
is the metadata record, store the position before the first user record
in the tree.

In the function QUICK_RANGE_SELECT::init_ror_merged_scan we create a seperate handler if the handler in
head->file cannot be reused. The flag free_file tells us if we have a seperate handler or not.
There are cases where you might create a handler and then there might be a failure(running ALTER)
and then we have to revert the handler back to the original one. The code does that
but it does not reset the flag 'free_file' in this case.
Also backported f2c41807.