Write GTID sets, not just last executed GTID into WAL

[yoshinorim]

This is a subtask for https://github.com/facebook/mysql-5.6/issues/474 . The purpose of this feature is support binlog_order_commits=0 in MyRocks.

Currently, MyRocks writes last executed binlog filename, position, and GTID into WAL (eventually persisted to system CF) at transaction commit. GTID is the last executed GTID, and it does not include GTID sets. If using binlog_order_commits=0, WAL write ordering is not guaranteed to be same as binlog ordering, so last executed binlog position/GTID may not include all executed transactions, so binlog pos/GTID from WAL can't be trusted anymore.

Some tools like myrocks_hotbackup and crash safe master rely on this feature. Both require to find the last executed binlog position (or GTID), then configure replication based on the position. So currently binlog_order_commits=1 is needed. A big side effect is it degrades performance a lot, as written in #474.

To make binlog_order_commits=0 work in MyRocks, it is necessary to write GTID sets, not just last executed GTIDs into WAL at commit. By doing so, on crash recovery, it will be possible to identify all executed transactions, and configure replication based on that. There are some technical uncertainties to implement this feature.

• Record format -- I'd strongly prefer single row (i.e. key=dictionary key id, value= binlog gtid sets). Multiple rows will make purging rows necessary, which will make things complicated.
• How to compose GTID sets at commit -- I assume merge operator would be useful
• How to write less -- for example, server A (uuid3) might have very long GTID sets like uuid1:1-123,uuid2:1-10,uuid3:1-20.... and only uuid3 is updated. In that case, updating uuid1 and uuid2 is not needed, since they do not change.

[yoshinorim]

Another important point is with ordering commits, if a transaction takes long time at commit() (e.g. writing large data into MemTable), all other transactions need to wait. This is a consequence of the serialized commits. This is a debugging code to reproduce the issue (https://gist.github.com/yoshinorim/68ba74e3acd5b7fc6629250072f79455). With disabling ordered commits, long time commit() doesn't block other transactions.