DESCRIPTION
===========
Transactions could binlog a last_commited smaller than expected. With the wrong
last_commited values, the transactions which sould be applied sequentially could
be applied parallel. That caused applier errors or data inconsistency.

ANALYSIS
========
When committing a transaction, its last_commited is set to the value of
max_committed_transaction. max_committed_transaction is the maximum
sequence_number of committed transactions. It is maintained just before
committing each transaction to engine. If its sequence_number is not
SEQ_UNINIT then updates max_committed_transaction accordingly.

However, it checked wrong sequence_number(the sequence_number of the
leader thread's transaction instead of the sequence_number of the transaction).
That caused that max_committed_transaction was only updated in time for leader
thread's transaction. The update for following transactions were delay to
finish_commit() which was after the transaction commited to engine.

FIX
===
Just checks its own sequence_number of each transaction instead of the
sequence_number of the leader thransaction.