Self-recovery of TxPool max capacity

[marcindsobczak]

Changes

• if TxPool/BlobPool capacity is exceeded, remove 2 worst txs instead of 1 (when inserting new tx)

It will not be used in normal workflow - only if TxPool/BlobPool capacity will be exceeded, which is not expected, but rarely observed on devnet nodes

Types of changes

• Bugfix (a non-breaking change that fixes an issue)
• New feature (a non-breaking change that adds functionality)
• Breaking change (a change that causes existing functionality not to work as expected)
• Optimization
• Refactoring
• Documentation update
• Build-related changes
• Other: Description

Testing

Requires testing

• Yes
• No

If yes, did you write tests?

• Yes
• No

[LukaszRozmej]

Why not remove in loop until under limit?

[marcindsobczak]

Loop was my initial idea. Changed it to just double removal, because it will do a job as well and seems more secure - we will avoid potential long lock. And I expect that it will solve the problem at the very beginning, when capacity will be exceeded by 1 item above expected - so removing one should be enough to drop below max cap

[marcindsobczak]

And out removed item will not be accurate (we will return only one removed item instead of 2), but it is just recovery option which will be used only in emergency, so IMO not worth to refactor a lot of code to address it