core/txpool: allow tx and authority regardless of admission order

[LuisPH3]

This PR proposes a change to the authorizations' validation introduced in commit cdb66c8. These changes make the expected behavior independent of the order of admission of authorizations, improving the predictability of the resulting state and the usability of the system with it.

The current implementation behavior is dependent on the transaction submission order: This issue is related to authorities and the sender of a transaction, and can be reproduced respecting the normal nonce rules.

The issue can be reproduced by the two following cases:
First case

• Given an empty pool.
• Submit transaction { from: B, auths [ A ] }: is accepted.
• Submit transaction { from: A }: Is accepted: it becomes the one in-flight transaction allowed.

Second case

• Given an empty pool.
• Submit transaction { from: A }: is accepted
• Submit transaction { from: B, auths [ A ] }: is rejected since there is already a queued/pending transaction from A.

The expected behavior is that both sequences of events would lead to the same sets of accepted and rejected transactions.

Proposed changes
The queued/pending transactions issued from any authority of the transaction being validated have to be counted, allowing one transaction from accounts submitting an authorization.

• Notice that the expected behavior was explicitly forbidden in the case "reject-delegation-from-pending-account", I believe that this behavior conflicts to the definition of the limitation, and it is removed in this PR. The expected behavior is tested in "accept-authorization-from-sender-of-one-inflight-tx".
• Replacement tests have been separated to improve readability of the acceptance test.
• The test "allow-more-than-one-tx-from-replaced-authority" has been extended with one extra transaction, since the system would always have accepted one transaction (but not two).
• The test "accept-one-inflight-tx-of-delegated-account" is extended to clean-up state, avoiding leaking the delegation used into the other tests. Additionally, replacement check is removed to be tested in its own test case.

Expected behavior
The expected behavior of the authorizations' validation shall be as follows:

Notice that replacement shall be allowed, and behavior shall remain coherent with the table, according to the replaced transaction.

[LuisPH3]

Hi @lightclient. I haven't managed to get CI to run in Image: Visual Studio 2019; Environment: GETH_ARCH=386, GETH_MINGW=C:\msys64\mingw32. I have noticed that other PRs fail in the same step.
How can I solve this issue?

[MariusVanDerWijden]

@LuisPH3 This is a known timeout/flaky test. We will not block merging PRs on this test not passing

[lightclient]

Generally okay with the idea here. It doesn't seem terribly important though since we shouldn't really expect that a user will be sending both a delegation and tx at the same time. Since the change is small though, I don't see a reason to not do it.

Pushed a small change to simplify the logic for counting the in-flight txs.

[rjl493456442]

My concern is that if we also consider the blobPool, the new rule will become even more complex.

delegation || pending auth:
=> at most one non-blob tx
=> at most one blob tx

at most one non-blob tx && at most one blob tx:
=> accept pending auth

more than one non-blob tx || more than one blob tx:
=> reject pending auth

[lightclient]

In #31373 I removed the test-only reserver and in hindsight I think this is a mistake. It's useful to panic when some assumptions about double holds and double releases fail. Adding it back here.

[lightclient]

I think this change is small enough that it's okay to include. Allowing tx and authority regardless of order doesn't seem that important too me, but considering the change itself is only around 10 lines of code and the reset is fixing up some tests and me refactoring the Reserver object, it's reasonable.

The blobpool will still require specific order if the user wants to pool both a delegation and a blob tx. I think this is okay since we expect blob users to generally be EOAs managed by rollups.