sync_transaction accepts stale sync message as a fresh one

If one server is very slow to respond to the transaction sync query and another one is faster and deliver the sync, a subsequent transaction may end up being acknowledged by the older stale sync if both servers suddenly stop replicating (i.e. lose the Slave status).

This happens because the bookkeeping for the syncs does not uniquely identify which transaction is being synced and instead keeps track of how many are ongoing. This works in most cases but in the aforementioned case, this isn't enough information to know that the sync is stale.

The solution is to embed the GTID being synced into the sync payload.