Galera GTID autorecovery

Currently when --galera-info is specified XtraBackup queries the
following Galera variables to retrieve GTID and store it in
xtrabackup_galera_info file as a part of the backup process:

wsrep_local_state_uuid
and
wsrep_last_committed.

The drawback is that one has to block commits in one way or another to
guarantee consistency of wsrep_last_committed with redo log and data
files. Currently it is done under FTWRL, and with the backup locks it
would require blocking all commits even with binary log disabled.

However, a Galera node also stores GTID in the InnoDB system trx header,
similar to binary log coordinates stored in xtrabackup_binlog_pos_innodb
and slave coordinates in the ‘crash safe slave’ feature in Percona
Server 5.1/5.5.

Thus a more efficient way to retrieve GTID when backing up a server with
backup locks support would be to read the corresponding values from the
InnoDB trx header on recovery and create xtrabackup_galera_info on that
stage. There is a magic value field for Galera GTID coordinates (see
TRX_SYS_WSREP_XID_MAGIC_N_FLD and TRX_SYS_WSREP_XID_MAGIC_N), so it is
easy to only do so for Galera backups automatically.