Add Mariabackup option to set gtid_slave_pos to original server's gtid_current_pos during prepare

Many users use Mariabackup to build slaves using the process outlined in the following documentation page:

https://mariadb.com/kb/en/library/setting-up-a-replication-slave-with-mariabackup/

One problem with this process is that Mariabackup doesn't back up and restore the original server's entire GTID state, which can be considered to be the value of gtid_current_pos.

https://mariadb.com/kb/en/library/gtid/#gtid_current_pos

The value of gtid_current_pos is constructed from the values of two other system variables--gtid_slave_pos and gtid_binlog_pos.

https://mariadb.com/kb/en/library/gtid/#gtid_slave_pos

https://mariadb.com/kb/en/library/gtid/#gtid_binlog_pos

Mariabackup does back up and restores the original server's value for gtid_slave_pos, because that information is stored in mysql.gtid_slave_pos, which is an InnoDB table.

https://mariadb.com/kb/en/library/mysqlgtid_slave_pos-table/

Mariabackup does not currently back up and restore the original server's gtid_binlog_pos, because that information is stored in the binary logs, which are not backed up.

This means that a server restored from a backup is missing some GTID state by default.

Mariabackup does back up the original server's value of gtid_current_pos in the xtrabackup_binlog_info file.

https://mariadb.com/kb/en/library/files-created-by-mariabackup/#xtrabackup_binlog_info

This means that if a user wants to build a slave using a backup, then they can restore the backup, and then they can extract the original server's gtid_current_pos from xtrabackup_binlog_info:

$ cat xtrabackup_binlog_info

mariadb-bin.000096 568 0-1-2

And then the user would need to use this value to set the value of gtid_slave_pos, and then they could set up replication:

SET GLOBAL gtid_slave_pos='0-1-2';

CHANGE MASTER TO

  ...

  MASTER_USE_GTID=slave_pos;

Some users would prefer if the value of gtid_slave_pos would automatically be set to the original server's gtid_current_pos when a backup was prepared. That way, users would not have to worry about manually fixing the GTID state, and they could just set up replication from a slave created from a backup by doing something like this:

CHANGE MASTER TO

  ...

  MASTER_USE_GTID=slave_pos;

And the slave would automatically know where to start replicating from.