fix(miner): fix repeatedly processing dropped txs in a new block

[0xmountaintop]

1. Purpose or design rationale of this PR

txs.Shift() and txs.Pop() will only drop the tx from the current txs *types.TransactionsByPriceAndNonce. However, the "dropped" tx is not really removed from the mempool, and will still be fed into commitTransactions when making a new block.
(You can verify this statement using #492. Can try and play around using https://github.com/HAOYUatHZ/ccc-tester, changing https://github.com/HAOYUatHZ/ccc-tester/blob/ccc/docker/l2geth/Dockerfile to scrolltech/l2geth:scroll-v4.3.56-PoC).

This PR removes the txs from the processing tx queue. (update: This PR now removes the txs from the txpool. See discussion below.) Besides, it makes no sense to re-trace the tx, if such a single tx is already known circuitcapacitychecker.ErrBlockRowConsumptionOverflow or circuitcapacitychecker.ErrUnknown

Note: L1msg is not affected by this because we read and maintain the queue in db instead of reading directly from mempool.

2. PR title

Your PR title must follow conventional commits (as we are doing squash merge for each PR), so it must start with one of the following types:

• build: Changes that affect the build system or external dependencies (example scopes: yarn, eslint, typescript)
• ci: Changes to our CI configuration files and scripts (example scopes: vercel, github, cypress)
• docs: Documentation-only changes
• feat: A new feature
• fix: A bug fix
• perf: A code change that improves performance
• refactor: A code change that doesn't fix a bug, or add a feature, or improves performance
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
• test: Adding missing tests or correcting existing tests

3. Deployment tag versioning

Has the version in params/version.go been updated?

• This PR doesn't involve a new deployment, git tag, docker image tag, and it doesn't affect traces
• Yes

4. Breaking change label

Does this PR have the breaking-change label?

• This PR is not a breaking change
• Yes

[0xmountaintop]

A more performant way is to change (pool *TxPool) removeTx to a public function, and explictedly call it to remove the tx, instead of simply skipping it. But not sure whether that style will introduce some risks in the future.

[0xmountaintop]

Update: I've changed my mind. We should remove the tx from the txpool. Otherwise if a user uses the nonce with PendingNonceAt to send a tx, the new tx will get stuck, because the previous tx is stuck in the txpool

[icemelon]

I wonder if the rpc node will remove the tx after the signer does so. Otherwise, users will get the incorrect nonce from the rpc node.

[0xmountaintop]

I wonder if the rpc node will remove the tx after the signer does so. Otherwise, users will get the incorrect nonce from the rpc node.

I will run a local testnet to check.