WL#4105: Online backup: Save slave status

RATIONALE
=========

When backing-up a server which is a replication slave, it would be useful to
know what was the last master event applied at the time of VP. Then, after
restoring the slave, replication could be restarted from the correct position.

The online backup system should be able to store that information inside backup
image. Specifically, position of the last replication event applied in the
server at the time of VP.

(support request from Riga meeting on WL#4209) The binlog positions should also 
be added to error log to make it easier to diagnose problems.

Note that in multi-master setting, positions for each master must be saved.

This worklog shall also produce tests that satisfy the following:

* Create tests that inspect the binary log to verify neither the backup
  or restore or any of their effects are written to the binary log
  and/or replicated to the slave. This is being done as part of WL#4195
  but may be augmented by this work.
* Test correct location of the master's binlog is saved in the backup
  image. 


Remarks by Guilhem:
> Please consider this scenario:
> - master -> slave; slave has binlog disabled (as it's useless)
> - master is so important that we don't want to take an online backup
> of the master (can't bear the speed penalty, not enough free disk,
> etc)
> - so we want to take a backup of the slave, and it will be as good as
> a backup of the master. First way is stop slave threads, do a cold
> backup of the slave. Second way: do an online backup of the slave:
> then that backup needs to correspond to some SHOW SLAVE STATUS
> position. I mean, by hand with today's tools one would do:
> FLUSH TABLES WITH READ LOCK; # or LOCK TABLES READ on all tables
> SHOW SLAVE STATUS; # and remember what master binlog position it tells
> mysqldump ...
> UNLOCK TABLES;
> and then that backup can later be restored on any new slave ("slave
> cloning").
> If we try to translate that into the new online backup, SHOW SLAVE
> STATUS should be used instead of step 4 of WL#3956 in that particular
> case, and either lock() should freeze the engine, or the commit
> blocker should be used even if binlog is disabled.
> SHOW SLAVE STATUS is however updated non-atomically, I mean it works
> like this in the slave:
> - commit transaction
> - update rli's content (==relay-log.info's content==SHOW SLAVE STATUS' 
content)
> 
> So, again the VP can be between the two, if bad luck.
> Maybe storing relay-log.info into a table would help.

Notes
-----
* WL#4209 introduced saving the master's binlog file and position to
  the backup_progress log. Additional work is needed to ensure this
  information is also saved in the backup image file.