Optimize relay_log.info Flush

The file relay_log.info maintains the execution state of the slave SQL thread, so it can restart in the correct place in the relay log. This state is stored using binlog file coordinates (i.e. filename and offset), and is updated/synced for each transaction in the binary log. This file was required before GTIDs were around to ensure that the slave could start at the correct position after it had stopped. However, now that GTIDs exist, we can automatically find the correct transaction in the relay log to start replicating from based on the GTID state of the slave. This optimization will remove a flush/fsync per transaction.

Kudos go to knielsen for discovering this issue.