Problem:
--------
Slave does not report Seconds_Behind_Master when running
with MTS.

How Seconds_Behind_Master is calculated?
----------------------------------------

When the slave is actively processing updates, Seconds_Behind_Master
shows the difference between the current timestamp on the slave and
the original timestamp logged on the master for the event currently
being processed on the slave.

Seconds_Behind_Master= Current timestamp - mi->rli->last_master_timestamp
                       - mi->clock_diff_with_master

In some cases, slave's clock can be different from master's clock.
In order to support non-identical clocks, 'clock_diff_with_master'
is also taken into consideration so that SBM is correct.

Description:
------------
Coordinator thread, when it finds out that worker queue(GAQ)
is empty, sets rli->last_master_timestamp to zero.  For
any further events, rli->last_master_timestamp is not
updated and thus SBM doesn't show replication lag.

There is also another issue associated with this bug.
When a worker commits a transaction, mts_checkpoint_routine
calls rli->reset_notified_checkpoint function where it sets
the rli->last_master_timestamp.

While doing that, instead of fetching the timestamp from the
first group of the Slave_committed_queue, it fetches the
timestamp from the last checkpoint and assigns it to
rli->last_master_timestamp.

This needs to be fixed as it results in inaccurate SBM.

Fix:
----
rli->last_master_timestamp is assigned from the first
event from the master when all slave workers are
waiting for events from the Coordinator.

When a worker commits a transaction, the coordinator thread
fetches the timestamp from the first group of the
Slave_committed_queue and assigns to rli->last_master_timestamp.