Fix for galera_3nodes galera_ipv6_mysqldump and galera_ipv6_mariabackup

WSREP_LIB_MAINTAINER_MODE was introduced in wsrep-lib cmake options
to enable -Werror. The maintainer mode is disabled by default in order
not to fail compilation on every compiler warning. The wsrep-lib
maintainer mode can be enabled via -DWSREP_LIB_MAINTAINER_MODE:BOOL=ON.

* Made galera_3nodes.galera_ipv6_mariabackup deterministic with respect
  to donor selection, fixed assert grep definitions to match
  Galera 4 behavior and recorded.
* Removed extra connection setup from galera_3nodes.galera_ipv6_mysqldump
  and recorded.

Call to wsrep_handle_SR_rollback was missing check that wsrep_on is true.

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

Restore changes from 10d347dc that were lost in a merge

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.

Update wsrep-lib to have OSX compilation fixes

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.

The computation about which "fraction" of range/ref access cost we will
need to perform, was incorrect.

Adjusted the computation.

Make the "ORDER BY ... LIMIT n" optimizer take into account condition
selectivity data from EITS (not just from potential range accesses).