Description
-----------
With filter being set on slave, if non-filtered transaction comes post `XA
ROLLBACK` then it results into ASSERTION failure
`thd->get_ha_data(ht_arg->slot)->ha_ptr_backup == __null ||
(thd->get_transaction()->xid_state()-> has_state(XID_STATE::XA_ACTIVE))` at
handler.cc:1396 in trans_register_ha.

Analysis
--------
The replication of empty XA transaction is not currently supported due to the
"read-only optimization" covered in the X/Open XA transaction standard.
Furthermore, the usage of replication filters together with XA transaction is
also not supported.

The assertion occurs because the data engine plugins that initialize Ha_data
and are called upon `XA START`, are not properly called back to release
resources, after `XA PREPARE`, due to the transaction being emptied upon
applying replication filters. One possible reason for this is that the filtered
statements are not skipped, instead, they are applied but with no actual impact
either in the data engine or the binlog.

In addition, the internal state of the data engine transaction is changed when
using `*-log-info-repository=TABLE`, since the `current_thd` is used to perform
the system tables update.

All of the above leaves the replication transaction context state inconsistent
with the data engine native transaction state, leading, either to the above
assertion being emited or a segmentation fault being hit when the engine plugin
tries to use the internal transaction.

This problem is present in 5.7 but it got visible in 8.0.5 because of WL#10474
making `*-log-info-repository=TABLE` the default options.

Fix
---
This patch doesn't solve the overall issue, dealing with XA transactions working
together with replication filters. Instead, adds an error message warning about
the unsupported features and adds some validations that will allow the slave to
continue running without the stated assertion being met, although in an
undetermined state:

1. Output an error message stating the unsupported feature of using XA
   transactions together with replication filters.

2. Mirror acquisition of `THD` transaction data - `detach_*` functions - when
   reliquishing the same transaction data - `attach_*` functions - and use this
   execution flow when the `Ha_trx_info` has been cleared and is `nullptr`, in
   `xa.cc: attach_native_trx()`.

3. In the engine data plugin function handling attaching and detaching of the
   native transaction, allow for an empty state, meaning, include a state where
   the current `THD` doesn't have any native transaction associated - output of
   using tables to store the metadata.