Support for gtid-errant-reset-master command; formalized GTID sets

[shlomi-noach]

This PR introduces the gtid-errant-reset-master command, applied on an instance:

• If instance is using Oracle's GTID
• And has errant GTID transactions (see GTID errant transaction detection #607)
• And has no replicas

Then this command "fixes" errant GTID transactions by way of RESET MASTER; SET GLOBAL gtid_purged....
This command is of course destructive to the server's binary logs. If any app is tailing the logs (https://github.com/github/gh-ost, other), or if binary logs are assumed to enable incremental restore, then this command is dangerous.

---

Also, GTID sets are more formally parsed. An old unused OracleGtidSet piece of code is revived.

[shlomi-noach]

Web interface adds a "fix" button:

Command line looks like this:

orchestrator-client -c gtid-errant-reset-master -i myserver:3306

[shlomi-noach]

Noting that errant GTID detection is incorrect for 2nd, 3rd, ... tier replicas, and is only correct for 1st tier replicas.

This is because of our way of asynchronously checking master & replicas, and where we heuristically discard master's UUID from the GTID set. However, we do not discard master's master UUID, nor 3rd degree master, ...
I need to think this over.

[shlomi-noach]

2nd, 3rd, ..., nth tier errant GTID is now resolved correctly via introduced ancestry_uuid.

Retries on reset master and set global gtid_purged reduce risk of this dangerous operation breaking halfway through. Clear error messages indicate what the intended operation was and what the value of gtid_purged was expected to be, so that if something bad does happen, Web UI, CLI and the logs, all provide with sufficient info for a human to set things right.