[BUG] Consumed aborted txn messages

[superhx]

Problem cause:
ElasticLogFileRecords return relative last offset cause missing scan the abort txns

ex.

• seg-0 contains records 0, 1
• seg-1 contains records 2, 3, 4, and 2, 4 is aborted

When fetch from offset=2, the ElasticLogFileRecords return records (2, 3, 4) with relative endOffset = 2. Then the ElasticLog will only collect aborted txn index 2 to the fetch result. It will cause the client to treat 4 is a committed message.