binlog-optimize-thread-scheduling=0 case of binlog rotate via FLUSH LOGS may obsolate binlog file too eary

A race described in MDEV-24526 is not fixed over there for a case of the server started
with a non-default --binlog-optimize-thread-scheduling=0.
Specifically a group of committing transaction threads need to lock a sequence
of mutexes LOCK_log, LOCK_after_binlog_sync, LOCK_commit_ordered in a crabbing manner, that is with releasing the preceding mutex upon acquisition of the current one.
MYSQL_BIN_LOG::trx_group_commit_leader() shows the pattern for the default
--binlog-optimize-thread-scheduling=1.