Thread executing wsrep transaction can't change during transaction
execution. Similarly, thread executing high priority brute force
(BF) transaction does not change during transaction execution.
Therefore, in both cases there is no need to call server
code after transaction has initialized.

InnoDB already stores information is this wsrep transaction to
trx_t::wsrep and this is checked using trx->is_wsrep() function.
Because, brute force transaction is always a wsrep transaction
we can extend trx_t::wsrep variable so that value

0 == not wsrep transaction (and not BF)
1 == normal wsrep transaction
2 == high priority BF wsrep transaction
4 == high priority BF transaction is performing unique secondary index scan

These values can be set by calling server code on innobase_trx_init().
After that we can use trx_t::is_wsrep() and new function
introduced in this patch trx_t::is_wsrep_BF(). Unique
secondary index scan is determined later but it implies BF,
so this patch removes unnecessary variable trx_t::wsrep_UK_scan.
Patch introduces new functions trx_t::is_wsrep_UK_scan(),
wsrep_begin_UK_scan() and wsrep_end_UK_scan() to handle
unique secondary index scan.

This change reduces number of calls to server code from InnoDB and
reduces code bloat on performance critical stages like acquiring
record locks. Furthermore, it simplifies code on several locations.

This patch also removes unnecessary trx_t::wsrep_event that
was always set to NULL and not used.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

A call to

  dbug_print_join_prefix(join_positions, idx, s)

returns a const char* ponter to string with current join prefix,
including the table being added to it.

Test seems to pass reliably now.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

Fixing the regression happening with galera.galera_toi_ddl_nonconflicting
The problem, surfaced by the test, was due to multi-statement used in the test.
The test issues two queries, as multi-statement:

--send ALTER TABLE t1 ADD COLUMN f3 INTEGER; INSERT INTO t1 (f1, f2) VALUES (DEFAULT, 123);

With this, the session's THD structure has in query_string member
the full multi-statement, and this was used as base query in
TOI replication rewriting.

The fix is to pass actual length of the ALTER statement part for
TOI replication.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

If user has specified the desired alter algorithm by using session
variable alter_algorithm, and not specifying the algorithm in the
ALTER SQL statement, then the ALTER will be processed in sending node
according the algorithm chosen by the alter_algorithm variable.
But in receiving nodes, appliers cannot see this session variable,
and will use the default algorithm when executing the ALTER.

The fix in this commit, will check if user has set alter_algorithm
variable and has not specified the algorithm clause in the ALTER
statement, and in such case will rewrite the original ALTER statement
appended by the algorithm clause. This rewritten ALTER statement will
be used in replication.

The commit has also new mtr test: galera.galera_alter_table_algorithm
which verifies that ALTER query rewrite happens when needed
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

Added new test scenario in galera.galera_bf_kill
test to make the issue surface. The tetst scenario has
a multi statement transaction containing a KILL command.
When the KILL is submitted, another transaction is
replicated, which causes BF abort for the KILL command
processing. Handling BF abort rollback while executing
KILL command causes node hanging, in this scenario.

sql_kill() and sql_kill_user() functions have now fix,
to perform implicit commit before starting the KILL command
execution. BEcause of the implicit commit, the KILL execution
will not happen inside transaction context anymore.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

It's read for every command execution, and during slave replication
for every applied event.

It's also planned to be used during write set applying, so it means
mostly every server thread is going to compete for the mutex covering
this variable, especially considering how rarely it changes.
Converting wsrep_ready to atomic relaxes the things.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

Add wait_until_ready waits after wsrep_on is set on again to
make sure that node is ready for next step before continuing.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

Stabilize test by reseting DEBUG_SYNC and add wait_condition
for expected table contents.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

The crash report terminates prematurely when Galera library was
not loaded.

As a fix, check whether the provider is loaded before shutting down
Galera connections.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

All the options that where in buildbot, should
be in the server making it accessible to all
without any special invocation.

If WITH_MSAN=ON, we want to make sure that the
compiler options are supported and it will result
in an error if not supported.

We make the -WITH_MSAN=ON append -stdlib=libc++
to the CXX_FLAGS if supported.

With SECURITY_HARDENING options the bootstrap
currently crashes, so for now, we disable SECRUITY_HARDENING
if there is MSAN enable.

Option WITH_DBUG_TRACE has no effect in MSAN builds.

This is a limitation of the view protocol.
Tests were fixed with workaround (via disable/enable service connection)

Each time a listener socket becomes ready, MariaDB calls accept() ten
times (MAX_ACCEPT_RETRY), even if all but the first one return EAGAIN
because there are no more connections.  This causes unnecessary CPU
usage - on our server, the CPU load of that thread, which does nothing
but accept(), saturates one CPU core by ~45%.  The loop should stop
after the first EAGAIN.

Perf report:

    11.01%  mariadbd  libc.so.6          [.] accept4
     6.42%  mariadbd  [kernel.kallsyms]  [k] finish_task_switch.isra.0
     5.50%  mariadbd  [kernel.kallsyms]  [k] _raw_spin_unlock_irqrestore
     5.50%  mariadbd  [kernel.kallsyms]  [k] syscall_enter_from_user_mode
     4.59%  mariadbd  [kernel.kallsyms]  [k] __fget_light
     3.67%  mariadbd  [kernel.kallsyms]  [k] kmem_cache_alloc
     2.75%  mariadbd  [kernel.kallsyms]  [k] fput
     2.75%  mariadbd  [kernel.kallsyms]  [k] mod_objcg_state
     1.83%  mariadbd  [kernel.kallsyms]  [k] __inode_wait_for_writeback
     1.83%  mariadbd  [kernel.kallsyms]  [k] __sys_accept4
     1.83%  mariadbd  [kernel.kallsyms]  [k] _raw_spin_unlock_irq
     1.83%  mariadbd  [kernel.kallsyms]  [k] alloc_inode
     1.83%  mariadbd  [kernel.kallsyms]  [k] call_rcu

put the command line at the end. so that when a very long command line
is truncated, it doesn't take the actual error message with it

set transferfmt in .cnf file like other galera tests do.
otherwise it defaults to socat when mtr detected that only nc is available

Bring info about cause of closing connection in the place where we increment
statistics to do it correctly.

MDEV-32891 Assertion `value <= ((ulonglong) 0xFFFFFFFFL) * 10000ULL' failed in str_to_DDhhmmssff_internal

Fixing the wrong assert.

MDEV-31302 Assertion `mon > 0 && mon < 13' failed in my_time_t sec_since_epoch(int, int, int, int, int, int)

The code erroneously called sec_since_epoch() for dates with zeros,
e.g. '2024-00-01'.
Fixi: adding a test that the date does not have zeros before
calling TIME_to_native().

MDEV-31221 UBSAN runtime error: negation of -9223372036854775808 cannot be represented in type 'long long int' in my_strtoll10_utf32

The code in my_strtoll10_mb2 and my_strtoll10_utf32
could hit undefinite behavior by negation of LONGLONG_MIN.
Fixing to avoid this.

Also, fixing my_strtoll10() in the same style.
The previous reduction produced a redundant warning on
CAST(_latin1'-9223372036854775808' AS SIGNED)

MDEV-28386 UBSAN: runtime error: negation of -X cannot be represented in type 'long long int'; cast to an unsigned type to negate this value to itself in my_strntoull_8bit on SELECT ... OCT

The code in my_strntoull_8bit() and my_strntoull_mb2_or_mb4()
could hit undefinite behavior by negating of LONGLONG_MIN.
Fixing the code to avoid this.

Updated tests: cases with bugs or which cannot be run
with the cursor-protocol were excluded with
"--disable_cursor_protocol"/"--enable_cursor_protocol"

Fix for v.10.5

Added ability to disable/enable (--disable_cursor_protocol/
--enable_cursor_protocol) cursor-protocol in tests. If
"--disable_cursor_protocol" is used then ps-protocol is also
disabled. With cursor-protocol prepare statement is executed
only once. For "--cursor-protocol" added filter for queries:
it is executed only for "SELECT" queries.

The loose regex for the MDEV-34539 test ended up
matching the opensuse in the path in buildbot.

Adjust to more complete regex including space,
backtick and \n, which becomes much less common
as a path name.

The failing test case validates Seconds_Behind_Master for a delayed
slave, while STOP SLAVE is executed during a delay. The test fixes
initially added to the test (commit b04c8575) added a table lock
to ensure a transaction could not finish before validating the
Seconds_Behind_Master field after SLAVE START, but did not address a
possibility that the transaction could finish before running the
STOP SLAVE command, which invalidates the validations for the rest
of the test case. Specifically, this would result in 1) a timeout in
“Waiting for table metadata lock” on the replica, which expects the
transaction to retry after slave restart and hit a lock conflict on
the locked tables (added in b04c8575), and 2) that
Seconds_Behind_Master should have increased, but did not.

The failure can be reproduced by synchronizing the slave to the master
before the MDEV-32265 echo statement (i.e. before the SLAVE STOP).

This patch fixes the test by adding a mechanism to use DEBUG_SYNC to
synchronize a MASTER_DELAY, rather than continually increase the
duration of the delay each time the test fails on buildbot. This is
to ensure that on slow machines, a delay does not pass before the
test gets a chance to validate results. Additionally, it decreases
overall test time because the test can continue immediately after
validation, thereby bypassing the remainder of a full delay for each
transaction.

MDEV-25900 Assertion `octets < 1024' failed in Binlog_type_info_fixed_string::Binlog_type_info_fixed_string OR Assertion `field_length < 1024' failed in Field_string::save_field_metadata

A CHAR column cannot be longer than 1024, because
Binlog_type_info_fixed_string::Binlog_type_info_fixed_string
replies on this fact - it cannot store binlog metadata for longer columns.

In case of the filename character set mbmaxlen is equal to 5,
so only 1024/5=204 characters can fit into the 1024 limit.
- In strict mode:
  Disallowing creation of a CHAR column with octet length grater than 1024.
- In non-strict mode:
  Automatically convert CHAR with octet length>1024 into VARCHAR.

The lsof utility is prone to blocking on system calls that
it uses to obtain information about sockets (or files, devices,
etc.). This behavior is described in its own documentation.
It has a '-b' option (in combination with warnings suppression
via '-w') that reduces the probability of blocking, introducing
new problems (luckily probably not relevant for our use case).
However, there is no guarantee that it will not hang on some
distributions, with some TCP/IP stack implementations, or with
some filesystems, etc. Also, of the three utilities that are
suitable for our purposes, lsof is the slowest. So if there
are other utilities that we use during SST, such as 'ss' or
'sockstat', it is reasonable to use them instead of lsof.
This commit changes the prioritization of utilities, it does
not need additional tests (besides the numerous SST tests
already available in the galera suites). If the system still
need to use lsof, this commit adds the '-b' and '-w' options
to it command line - to reduce the likelihood of blocking.

Removed handling of the long-unsupported xtrabackup_pid file,
as it is not even created by modern versions of mariabackup.
Instead, added stopping of the asynchronous process that
mariabackup runs (if it is still active) to the exception
handler.

This commit makes the SST script for mariabackup more
resilient to unexpected terminations or hangs while
mariabackup or when SST scripts in a previous session
are still running (in reality they were hung while
waiting for something).