Fix a potential lost wakeup for binlog_commit_wait_usec

If a transaction T1 needs to wait for a transaction T2, T2's commit will
skip the normal binlog_commit_wait_usec delay, in order not to needlessly
stall throughput.

This works by checking if T2 is already ready to commit. If so, it is woken
up. If not, we set a flag in T2 so that when it gets ready to commit, it
will do so immediately.

But there was a potential race due to insufficient locking, if T2 gets ready
to commit just at the point where T1 does the check. If the race hits, the
wakeup (and early commit) of T2 might be lost.

The race is only theoretical (from code inspection, no known test case), but
seems best to fix it anyway, by properly locking LOCK_prepare_ordered around
the check.

sql/log.cc

@@ -7664,14 +7664,13 @@ void
 MYSQL_BIN_LOG::binlog_trigger_immediate_group_commit()
 {
   group_commit_entry *head;
-  mysql_mutex_lock(&LOCK_prepare_ordered);
+  mysql_mutex_assert_owner(&LOCK_prepare_ordered);
   head= group_commit_queue;
   if (head)
   {
     head->thd->has_waiter= true;
     mysql_cond_signal(&COND_prepare_ordered);
   }
-  mysql_mutex_unlock(&LOCK_prepare_ordered);
 }
 
 
@@ -7690,9 +7689,11 @@ binlog_report_wait_for(THD *thd1, THD *thd2)
 {
   if (opt_binlog_commit_wait_count == 0)
     return;
+  mysql_mutex_lock(&LOCK_prepare_ordered);
   thd2->has_waiter= true;
   if (thd2->waiting_on_group_commit)
     mysql_bin_log.binlog_trigger_immediate_group_commit();
+  mysql_mutex_unlock(&LOCK_prepare_ordered);
 }