Documentation is updated with the following diff.

Currently we have a problems with the binary logs:

• We truncate transactions from the binary log that was already fully written there (and thus may be on the slave)
• When we truncate a half-written-transaction we don't take into account that a slave may have already got part of it and will reuse the GTID id if reconnecting to a master that died in the middle of writing the transaction to the binary log.

The fix should be:

• All fully written transactions in the binary log should roll forwards. The half or not written one should do rollback.
• In case of the master-slave connection closing before the slave gets a full transaction, it should reconnect to the master and ask for the 'transaction after the last fully received GTID.
  Alternatively it could use the last binlog file + position (which should work fine as the master binlog was truncated).

monty, to the fully written ones, when a server restarts having both rpl_semi_sync_MASTER,SLAVE_enabled, the semisync slave recovery does not check the first of the two. Hence a server intended to be a master, that is having rpl_semi_sync_MASTER_enabled = true rolls back transactions in doubt unnecessarily and possibly harmfully.

That's an issue. It could be trivially fixed with adding the check of rpl_semi_sync_MASTER_enabled and when it's true it would override.

The half-written is an issue only because the slave is reconnecting to a master that passed through the semisync recovery with the intent to become slave (such master may discard from its binlog a transaction being received by slave.
It will disappear when the new rpl_semi_sync_MASTER_enabled-based decision will be implemented.

monty, I filed MDEV-33424 for this plan which is about 1 line of code.

MDEV-33424 is not acceptable as it does not solve the issue at hand. Please fix this issue the way I have described!
To make things clear, this is how to fix this issue:

• rpl_semi_sync_slave_enable should not have anything to do with recovery.
• We should only delete things from the binary log that was found to be half written during recovery. This could be a new option that could default to always one.
  I personally don't think we need an option for this as this should always be safe to do (and should save disk space)
• We should that if a slave re-connects it should continue from the next transaction after the last full transaction it has read.
  In other words. if the slave reads GTID-1 and master crashes while reading GTID-2 then the slave should ask for 'next transaction after GTD-1'
  Alternatively it can ask the transaction based on the last binlog position it was using.