feat(tx-pool): fast reject transactions that cannot fit into a block

[colinlyguo]

1. Purpose or design rationale of this PR

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:

• [x] feat: A new feature

3. Deployment tag versioning

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

• [x] Yes

4. Breaking change label

Does this PR have the breaking-change label?

• [x] This PR is not a breaking change

[georgehao]

I think also need to catch errors.New("tx too big") error

[colinlyguo]

I think also need to catch errors.New("tx too big") error

if if !pool.chainconfig.Scroll.IsValidBlockSize(tx.Size()) { can catch all cases that "one tx cannot fit into a block", then we don't need to catch errors.New("tx too big") error for the moment, because these txs can at least fit into an empty block.

[georgehao]

if you don't deal with the error, the exist error tx will stay in the txpool forever

[omerfirmak]

A reboot will get rid of those txns, it is fine.

[colinlyguo]

It might be nice to add a test to avoid a regression in the future

added in 9cc2719.

[colinlyguo]

if you don't deal with the error, the exist error tx will stay in the txpool forever

makes sense. I also believe reboot and repropagation (then rejection by tx pool) can resolve this.