WL#1716: Less usage of LOCK_log in Binlog_dump threads

Interesting when there are many Binlog_dump threads (several slaves replicating
this master). When the Binlog_dump thread reads an event from a binary log, it
takes LOCK_log.
It could be changed like this (goal is to have less mutex locks):
- if Binlog_dump is reading a non-active binlog (one which is not the current
one), no need to LOCK_log. The rest applies when the read binlog is active:
- when a thread writes to the binary log, it updates a global variable called
"last_end_binlog_pos" with tell(binlog) after writing the event. This variable
needs to be protected by a mutex say LOCK_pos.
- a Binlog_dump thread does this:
lock LOCK_pos
if where_I_am_now(=tell(my_IO_CACHE)) >= last_end_binlog_pos
{
lock LOCK_log
read event
unlock LOCK_log
}
else
read event
unlock LOCK_pos.
So the only case where this thread takes LOCK_log is if it always up to date (=
not very loaded master).
One should be careful, as not using LOCK_log may cause race conditions when two
threads read the same IO_CACHE (quoting Monty "We need probably to do some small
changes in the shared io_cache to avoid concurrent read/writes as this is not
anymore protected with LOCK_log, but this shouldn't be that hard").