Write binlog row events for changes done by cascading FK operations

Current practice of writing binlog rows events (binlog_format==ROW) for data access which causes foreign key constraint cascade operation to update or delete rows in FK referencing table, is to write only the delete_row or update_row event for the referenced table row changes. The replication applier has then the duty to carry out same foreign key constraint checks that happened in the primary node, and to execute related cascade operations to update/delete referencing table rows exactly like what happened in the primary node.

This practice has turned out challenging to support, especially when parallel applying is configured or in case of multi-master topology, when writes can also happen in the slave node.

to simplify the logic needed for replication applying in slave side, the FK cascade processing, in the primary node, should write binlog events related to cascaded update or delete in the referencing tables. i.e. a delete_row event should be written for each cascading delete executed, and update_row event should be written for each cascading update executed.
With this, the replication applier can skip cascade operations. However, it should carry out the regular FK enforcing, just for checking the consistency

User should have the option to choose if cascade related events are written to binlog or not. Therefore, a new InnoDB variable should be added, e.g. global boolean variable: innodb_write_cascade_events . With this the primary node binary logging policy will determine if replication applying must process cascade operations or not. The fact that cascaded events have been written in primary node, should be marked by a new event flag, e.g. LOG_EVENT_CASCADE_EVENT. It is not safe to rely on innodb_write_cascade_events in slave nodes, configuration may be uneven.