This task is ensued by MDEV-742 and implements the 2nd part of the upstream's
Bug#76233, see MDEV-21469 for the 1st part.

XA Commit, Rollback and XA PREPARE execution on slave involves mysql.gtid_slave_pos update to indicate the slave execution status.
Unlike the regular transaction, that update can't be executed within the replicated XA.

Regardless of whether binlog is ON or FF, it has to be processed as a separate transaction to be two-phase-committed with the replicated one.
Specifically, in the XA-PREPARE case the mysql.gtid_slave_pos transaction gains a special xid that 'matches' the xid of the user one. It prepares "in parallel" with the replicated XA and when the latter prepare OKs, it commits.
In case of a crash in between recovery will search for all user prepared trx:s, and try to match
their xid:s. mysql.gtid_slave_pos trx that matches a user XA allows for accounting the user XA prepare as successful and mysql.gtid_slave_pos one then commits.

Similar method is applied to XA-COMMIT,ROLLBACK.