Handle XA_RBDEADLOCK on XA END while still calling XA ROLLBACK afterwards.

[PatrickMNL]

No description provided.

[PatrickMNL]

Unfortunately I have to make adjustments in this method once again (after applying fixes for MariaDB 10.6.12+ here #1317 and for MariaDB 11.8.3+ here #1585).

We have migrated to AWS Aurora MySQL and since then we were suffering from connections that remained in an invalid state after having suffered a deadlock (while using XA). The connection that suffered from the deadlock subsequently kept throwing:

MySqlConnector.MySqlException : XA_RBDEADLOCK: Transaction branch was rolled back: deadlock was detected

When debugging I noticed that on Aurora MySQL the issue we saw in #1317 is now occurring on the XA END call rather than the XA ROLLBACK call, causing the code to never call XA ROLLBACK, leaving the connection in an invalid state (causing any subsequent call to keep throwing the above exception).

To ensure compatibility it seems like we need to handle the case for both calls separately in the OnRollback scenario.

[PatrickMNL]

Proposal for fixing XA connection state not being reset properly on TransactionScope.Dispose for Aurora MySQL.

Fixes #1590

[bgrainger]

Thanks for the contribution!

Is it possible to add tests to make this failure happen deterministically (e.g., with the steps given in #1585 (comment)) to verify compatibility (and check for regressions) with the DBs used in the integration tests? (Unfortunately the integration tests don't run against Aurora, but do use MariaDB.)

[PatrickMNL]

Thanks for the response!

We are currently prepping for a production migration to AWS, so I won't be able to add that on the short term, but I am willing to have a go at it somewhere after that, that would hopefully be in 2 weeks or so.

For now we'll use a version build from my fork for the migration (without it Aurora wasn't usable for us).