MDEV-37229: Set proper trx isolation level for Wsrep system threads

[mariadb-DenisProtivensky]

• The Jira issue number for this PR is: MDEV-37229

Description

Every Wsrep system thread should run with READ_COMMITTED transaction isolation level to prevent issues caused by InnoDB gap locks.

The exception is statement-based replication for appliers, where REPEATABLE_READ is required by the server code. To account for that, set the isolation level before every applied event. It won't affect an already running transaction, but allows to handle both statement- and row-based replications accordingly. However, the problem might arise with the mixed replication format.

Apparently, there was a separate issue with applier thread variables: wsrep_plugins_post_init() would overwrite thd->variables for every applier thread and forget to restore proper default isolation level. Then, upon every server transaction termination,
trans_reset_one_shot_statistics() would set thread's isolation level to the one stored in thd->variables, thus spoiling the isolation level value for appliers.

Release Notes

TODO: What should the release notes say about this change?
Include any changed system variables, status variables or behaviour. Optionally list any https://mariadb.com/kb/ pages that need changing.

How can this PR be tested?

MTR test is updated.

Basing the PR against the correct MariaDB version

• This is a new feature or a refactoring, and the PR is based against the main branch.
• This is a bug fix, and the PR is based against the earliest maintained branch in which the bug can be reproduced.

PR quality check

• I checked the CODING_STANDARDS.md file and my PR conforms to this where appropriate.
• For any trivial modifications to the PR, I am ok with the reviewer making the changes themselves.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[mariadb-TeemuOllakka]

I think some elaboration is needed in this comment:

• As the transaction is already started in Wsrep_high_priority_service::start_transaction(), is the change of thd->tx_isolation fully effective here or does it just suppress some server level checks?
• Is it possible that the write set contains both row and query events? In this case a row event could start a transaction with ISO_READ_COMMITTED and the following query event would be actually executed with read-committed isolation as the thd->tx_isolation is effective only when the transaction is started.
• Should this apply only to DML or also to DDLs (which are replicated as TOI)?

[mariadb-DenisProtivensky]

I added a test that shows that mixed replication works for appliers, but I don't know if it's just a suppression of some server level checks or a true isolation level change. I would expect the former as InnoDB transaction is the same throughout the duration of a server transaction, and it seems that the isolation level is assigned to it only once from the beginning.
Regarding TOI, as it uses query events (statement-based replication), now it will run with REPEATABLE_READ.

[mariadb-TeemuOllakka]

Looks good