This patch improves support for SEQUENCEs when used with Galera.
The original ticket, MDEV-28971, comes with a test case showing that
the combination SEQUENCES do not work in combination with Galera's
streaming replication. To fix that, it is necessary to include the
contents of stmt cache when preparing a fragment for replication.

Additional testing showed that support for SEQUENCEs is broken, even
for regular transactions replicated through Galera. Galera did not
correctly implement the non-transactional semantics of SEQUENCEs.
For instance:
```
BEGIN;
INSERT INTO some_table VALUES(...)
SELECT NEXTVAL(s);
ROLLBACK;
```
should result in the `INSERT` to be rolled back, while the value
consumed SEQUENCE `s` by `NEXTVAL(s)`, can't be rolled back and must
be committed. This is problematic for Galera, as ROLLBACK results in
no writeset. Therefore, transactions that rollback voluntarily
rollback, or are rolled back due to cluster-wide conflicts, result in
SEQUENCEs that diverge throughout the cluster. Also, when binlogs are
enabled, those diverge too.
To fix this, we replicate the contents statment cache whenever a value
from a sequence is consumed. Allowing ROLLBACK to undo transactional
changes, while preserving the changes made to the SEQUENCEs.

Move replication from SEQUENCE::next_value() to
ha_sequence::write_row(). This has the following benefits:
1. We get replication of sequence SETVAL(), which was not working
2. In write_row(), first the pending row event is generated, and
   replicated before the row is written to storage engine.
   Should replication fail, we get rid of the pending row event and
   return the error.

Added tests for BF aborts, and a test that shows nodes can recover
sequence operations through IST (even after certification failure).