WL#6559: Optimize GTIDs for passive slave - store GTIDs in table

The purpose of this worklog is to make the server execute faster and use much 
less disk space, if the server is a replication slave that uses Global 
Transaction Identifiers and which is never going to be promoted to a master. 
This is achieved by allowing GTIDs to be used with binary log turned off and 
instead store GTIDs in a system table.

It is crucial for correct operation that GTIDs are durable. Currently, GTIDs can 
only be stored in the binary log, and therefore GTIDs cannot be used without the 
binary log. A master must always have the binary log on. A slave that is a 
candidate to be promoted to master during a failover also must always have the 
binary log on. However, a slave that is only used for read scale-out and is never 
going to become a master may not have any use for the transactions in the binary 
log, but it may have a use for the GTID feature (to fail over to a new master). On 
such a slave, storing GTIDs in a table instead of in the binary log can be a 
crucial optimization.

The table will require much less disk space than the binary log - in all 
practical situations it can be implemented so that it only requires small, 
fixed size. Moreover, the binary log requires a disk sync of its own, whereas a 
table can re-use the same disk sync that the storage engine uses to make the 
transaction durable.