fatxpool: report_invalid: do not ban Future/Stale txs from re-entering the view

[michalkucharczyk]

Description

Avoid banning future/stale transactions reported as invalid by the authorship module.

Note for reviewers

When re-org is handled by transaction pool, the view for new fork (Bn') is cloned from the tip of the other existing fork (Bn). The new view is not entirely re-validated during the maintain process (it will be revalidated in the background), so it may happen that it contains transactions that are ready on (Bn) but actually are not ready on (Bn'). All required (which are expected to be in retracted set) transactions are submitted to the new view, but order of txs in ready iterator is not updated.

The proper fix would require to re-build the the iterator - which is not trivial as we do not have tags for transactions for block Bn' yet. We could force retracted txs to be before ready transactions but it also does not feel to be a good solution - it still would be best effort trial.

For now allowing future transactions to re-enter the view immediately is in my opinion a good compromise. This PR is a quick fix and actually brings back behavior of txpool from before merging #6008. The bad thing is that incorrect transactions are detected during block authorship, but this situation to happen requires some specific pre-conditions which should be rare.

If this PR is not merged, some transaction will get included into blocks, only after DEFAULT_BAN_TIME_SECS, which is pretty bad.

[michalkucharczyk]

/cmd prdoc --bump minor --audience node_dev

[iulianbarbu]

LGTM!

[michalkucharczyk]

So I was thinking a bit about selecting the best view to clone from in case of forks - what we discussed in DMs. Leaving it here for the record.

Let's consider following situation:

                  B1[Q1..Qn]   ---  B2[R1..Rn]   
                  vr: R1..Rn        vr: S1..Sn
                /
               /
B0 [P1...Pn] -
vr: Q1..Qn     \
                \
                  B1'[...]   ---  B2'[...]   

Legend

Transactions (Q depends on P):
Pi <- Qi <- Ri <- Si <- Ti

Bn[P] - Block with transaction included
vr: - ready transaction in view for given block

Let's assume we re-org from B2 to B2'.

When selecting B2 as the source for clone, we risk that S1..Sn which are ready in the B2 view, will not reflect the reality of the actual state at B2'. Meaning that in worst case, the block builder will find all the transactions invalid (future), and empty block will be built.

I think, this is quite unlikely to happen. Very specific condition would need to happen: B1' and B2' block would need to NOT contain Q1..Qn + R1..Rn transactions, what means that pools on different nodes are heavily mis-aligned.

When selecting B0 as the source for clone, we would need to revalidate S1..Sn transactions, what may significantly increase maintain duration and may result in building empty block. Light ready_at will not help here because Q1..Qn (which are ready transcation that would be considered in ready_at light) are most probably already included in B1' (or B2').

So when looking at those two options it is still better to choose the tip of the other fork, because the likeliness of having proper (for state B2') is quite high.

And the scenario addressed in this PR is also likely to happen when we have chains of transcations. For independent transactions the issue will not happen - and we will save a lot validations comparing to cloning from B0.

It is also worth mentioning that we most likely have incoming transactions T1..Tn (not depicted) which are kept in the mempool. And once the view for B2' is cloned we also need to submit (what means validate) those transactions from the mempool.

[paritytech-release-backport-bot]

Created backport PR for stable2503:

• [stable2503] Backport #7777 #8112 with remaining conflicts!

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin backport-7777-to-stable2503
git worktree add --checkout .worktree/backport-7777-to-stable2503 backport-7777-to-stable2503
cd .worktree/backport-7777-to-stable2503
git reset --hard HEAD^
git cherry-pick -x 954d8571df26b5cc0d342c6c05d414bd6912f1cd
git push --force-with-lease