Fix revert txs and inconsistent state

[jjyr]

This PR fixes the potential inconsistent state during mem-pool reset.

Issue

Some users report they found txs revert after get the tx receipt.

Context:

The mem-pool reset it's state when receive new l2block, then calculate new state of the next block:

1. execute l2 withdrawals
2. execute l2 deposits
3. execute l2 txs

Unlike withdrawals & txs, the deposits is collected from layer1 CKB's cells, and the count of collected deposits is uncertain everytime.

This 'uncertain' causes the problem, every time we reset the mem-pool the deposits cells may changed, and new created accounts are changed, for example:

The first time mem-pool reset creates 3 accounts:

1. Deposit A(id: 100)
2. Deposit B(id: 101)
3. Contract Account(id: 102)

But when the mem-pool resets again, the accounts are changed:

1. Deposit A(id: 100)
2. Deposit B(id: 101)
3. Deposit C(id: 102)
4. Contract Account(id: 103)

In example, we collected another new deposit cell, the new deposit changes the id of contract account.

Solution:

This PR introduce a pending_deposits fields in the mem-pool. The new collected deposits cells are stored in the pending_deposits field.

Thus, everytime we reset mem-pool, we use the same pending_deposits to construct next block, so we can get consistent state.

There are two refresh strategy of pending_deposits:

• safety refresh: when there are no new accounts created in the mem-pool, we are safe to re-collect the deposits cells from CKB. Because this would not change id of accounts.
• forced refresh: when a deposit is found unavailable in the CKB chain or it's already processed by the l2 block, we are forced to refresh the deposits. (Apply a l2 block with deposits causes forced refresh, but this still a safety operation since the deposits is consist between l2 block and mem-pool state).