START SLAVE UNTIL to Support Timestamps

Users can control a point at which a replica will automatically stop applying events from the master via START SLAVE UNTIL. Currently, this only allows GTIDs and log-offsets (file-name, binlog offset), which usually requires users to manually examine the binary log on the master to find the exact transaction one wants to stop at. Often, users won't care about the specifics on the exact transaction to stop at, but rather the goal is to create a known/consistent state, e.g. across multiple different slaves (possibly of different masters). That is, it currently requires users to use mariadb-binlog to manually analyze the binary log files in the master server's binlog directory, find the transaction identifier (GTID or log-offset) of some transaction at the timestamp they want to stop the slaves at, and input that into their STOP SLAVE UNTIL command. With multiple masters, this process would need to be repeated for each master.

Extending the START SLAVE UNTIL options to consider timestamps would simplify the process to do this. To define inclusive/exclusive behaviors, it would be good to be consistent with the existing GTID-based keywords SQL_BEFORE_GTIDS and SQL_AFTER_GTIDS, i.e.

STOP SLAVE UNTIL SQL_BEFORE_TIMESTAMP=<timestamp>

or

STOP SLAVE UNTIL SQL_AFTER_TIMESTAMP=<timestamp>

Note that this feature is naturally "gtid-friendly", as after the slave automatically stops from the timestamp, the @@global.gtid_slave_pos of the server would be correct based on the last-applied transaction. Then, if one wanted to incrementally move this slave's state up, it could re-connect to a master at that state, or mariadb-binlog --start-position (using GTID mode) could be used to apply the transactions (provided they exist in a binlog, somewhere).