Document effects of secure_timestamp=YES for replication

From the description of secure_timestamp variable in the KB it's easy to assume that secure_timestamp=YES is the safest of values. It is worth mentioning that while YES is more secure from the perspective of protection against system versioning history tampering, for which it was introduced, it's fatal for replication and cannot be used on replication slaves, which is why there is the separate REPLICATION value. With secure_timestamp=YES any scenario when a value based on the timestamp is inserted in the statement mode can lead to discrepancy between master and slave and eventual replication abort.

Description: Restricts direct setting of a session timestamp. Possible levels are:
YES - timestamp cannot deviate from the system clock
REPLICATION - replication thread can adjust timestamp to match the master's
SUPER - a user with this privilege and a replication thread can adjust timestamp
NO - historical behavior, anyone can modify session timestamp

--source include/have_innodb.inc

--source include/have_binlog_format_mixed.inc

--source include/master-slave.inc

--let $rpl_server_number= 2

--let $rpl_server_parameters= --secure-timestamp=YES

--source include/rpl_restart_server.inc

--connection master

CREATE TABLE t (a DATETIME(6), b INT) ENGINE=InnoDB;

INSERT INTO t VALUES (NOW(6),1);

--connection slave

START SLAVE;

--connection master

UPDATE IGNORE t SET b = 2;

--sync_slave_with_master

--connection master

DROP TABLE t;

--source include/rpl_end.inc

Last_SQL_Error	Could not execute Update_rows_v1 event on table test.t; Can't find record in 't', Error_code: 1032; handler error HA_ERR_END_OF_FILE; the event's master log master-bin.000001, end_log_pos 0