fix(pending): Inconsistent pending state

[Trantorian1]

Pull Request type

• Bugfix

What is the current behavior?

Current Madara pending block storage functions as follows:

1. We clear the pending block.
2. We store the finalized block.
3. We flush the db.

The issue with this is that since #623 we are storing part of the pending block in RAM and this update is not being synchronized with the database.

Consider the following flow:

1. We receive a transaction tx.
2. We add it to the pending block.
3. User A queries the state of tx with getTransactionStatus.
4. We get ready to close the pending block, as part of this we clear the pending data in RAM.
5. User B queries the state of tx with getTransactionStatus.
6. We close the pending block.

What happens in that when A queries the state of tx we will return AcceptedOnL2, since that information is in the pending block. When B queries the state of tx again though, we will return a TrasactionHashNotFound error: this is because we have just cleared the pending state in RAM and have not yet updated the database to reflect this change.

What is the new behavior?

New database update flow is as follows:

1. We clear the pending block in db.
2. We store the finalized block.
3. We flush the db.
4. We clear the pending block in RAM.

This has the effect that pending information can no longer be lost until it has been updated in db. In out previous example, B would still receive AcceptedOnL2 since the state has not yet been flushed from RAM.

The latest_block_n was also updated to accommodate this change: now it is derived from the state of the pending block in RAM instead of db. This is so as to ensure that the node does not think we have finished flushing the pending block until the RAM cache has been cleared.

This also has the advantage that the pending block is now aware of its parent block number, which is useful in some WS RPC methods.

Does this introduce a breaking change?

No