In the situation of master crash discussed in https://mariadb.atlassian.net/browse/MDEV-6462 slave can recover now in terms that the partial transaction is rolled back and SQL thread execution position points to the same place in master's binlog as IO thread current position. But gtid_slave_pos is increased and contains GTID of the transaction that was never committed. Besides the confusion of what gtid_current_pos points to in such situation it can also lead to slaves skipping one transaction from master's binlog when writes continue to restarted master.

I'm attaching the one-line patch that fixes the problem along with extension to tests added in MDEV-6462 to check correctness of gtid_slave_pos. The patch also has one more test case that was showing transaction loss without the code fix. The patch is on top of latest 10.0 branch.

Note that the problem feels like https://mariadb.atlassian.net/browse/MDEV-4906 wasn't fixed fully. And the patch makes me wonder: should gtid_sub_id be actually reset to 0 inside cleanup_context()? Maybe without that there could be some other situations when gtid_slave_pos is wrong and has GTID of a rolled back transaction?