store claimTx into storage every deposit

[chengzhinei]

Closes #.

What does this PR do?

There is a serious problem when monitorTxs handle "ReviewMonitoredTx" and update the mtx.Nonce:

here, the mTx.Nonce may bigger than nonce, and the nonce will never updated. And all the mTx can not be sended.
We have saw this bug happend in X1, and it made the bridge function hanged until we use this fixed code.
And this bug caused to the next problem, the GER include more than 70000 txs, and it took more than 10 hours to create claimTx.
A ExitRoots may include many deposits, and during "processDepositStatus()", it builds claimTx(one claimTx may cost about 1s), but only when storage.Commit, the ClaimTx will be write into db, the whole process may cost more than 10 minutes. But during that time, the "monitorTxs" can't get the claimTxs, and no claimTx would be sended to L2, so the claim is slowed down.
And I made a change, every deposit builds a claimTx, it stores the claimTx into db immediately.

Reviewers

Main reviewers:

• @john
• @doe

Codeowner reviewers:

• @-Alice
• @-Bob

[cla-bot]

We require contributors/corporates @chengzhinei to read our Contributor License Agreement, please check the Individual CLA document/Corporate CLA document

[cla-bot]

We require contributors/corporates @chengzhinei to read our Contributor License Agreement, please check the Individual CLA document/Corporate CLA document

[cla-bot]

We require contributors/corporates @chengzhinei to read our Contributor License Agreement, please check the Individual CLA document/Corporate CLA document

[sonarqubecloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
5 Code Smells

No Coverage information
30.6% Duplication

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

[ARR552]

Hi, I don't see the problem since the nonce is only updated if the service get a nonce too low error. As all txs are sent sincronously, all of them must consume the nonce (success tx or revert). I think this situations could only a problem in your current implementation.
On the other hand, I see that your PR contains many other changes, not only the fix you have commented on the description.

[chengzhinei]

Hi, I don't see the problem since the nonce is only updated if the service get a nonce too low error. As all txs are sent sincronously, all of them must consume the nonce (success tx or revert). I think this situations could only a problem in your current implementation. On the other hand, I see that your PR contains many other changes, not only the fix you have commented on the description.

Thanks for your reply~
I'm sure that this problem is not only in the X1 implementation.
I have used the code [0xPolygonHermez](https://github.com/0xPolygonHermez/zkevm-bridge-service/releases/tag/v0.3.0) run a mock environment, and keep send bridge transactions for test, and this problem happened every time. I have not found the root cause why the nonce is too low, but this problem is always going to happen.
And in my opinion, as long as it into the "ReviewMonitoredTx()", the mTx.nonce should be updated with the latest value, no matter the new nonce is low or high.

Besides, the other changes wants to solve the problem I descripted before: "And this bug caused to the next problem, the GER include more than 70000 txs, and it took more than 10 hours to create claimTx.". The changes could add claimTx into storage every deposit instead of the logic that finish making the claimTxs of all the deposits then add all the claimTxs into storage.