MDEV-32631 : galera_2_cluster: before_rollback(): Assertion `0' failed

[janlindstrom]

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

Description

Test case changes only. Add wait_conditions to make sure nodes rejoin the cluster. Assertion itself should not be possible anymore as we do not allow sequences on Aria tables.

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?

TODO: modify the automated test suite to verify that the PR causes MariaDB to behave as intended.
Consult the documentation on "Writing good test cases".

If the changes are not amenable to automated testing, please explain why not and carefully describe how to test manually.

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.
• [x ] 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

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

[sysprg]

@janlindstrom Thanks for fixes for complex tests, but the fix does not include changes to the wsrep inserts or library code, it only includes changes to the tests - yes, this will solve the problems with the tests by bypassing the problematic scenario, but it will not fix anything for the user - if the user performs actions as in the original test, he will get a crash on assertion instead of a diagnostic telling him what he did wrong. The user should always get diagnostics clearly showing him what he is doing wrong, without crashing on assertion. Therefore, I am returning the pull request to you for revision. Please return it to me after adding some checks in the code that give diagnostics and avoid subsequent crash in the assertion form, or an explanation why it is impossible/very problematic to add such a check.

[janlindstrom]

@sysprg Problem is that this test does not reproduce the crash not when it is unchanged. I did small changes to make it pass as there was one timeout. If I correctly remember assertion can happen if you have MyISAM changes inside a transaction, this can't anymore happen because (1) we run so that mysql.gtid_slave_pos table is InnoDB as it is on release binaries and (2) because multi-engine changes containing non-transactional engines are now restricted on Galera. Therefore, there is nothing to be fixed on server code or in library code in this case.