core/txpool: add 7702 protection to blobpool

[rjl493456442]

This pull request introduces two constraints in the blobPool:

(a) If the sender has a pending authorization or delegation, only one in-flight
executable transaction can be cached.
(b) If the authority address in a SetCode transaction is already reserved by
the blobPool, the transaction will be rejected.

These constraints mitigate an attack where an attacker spams the pool with
numerous blob transactions, evicts other transactions, and then cancels all
pending blob transactions by draining the sender’s funds if they have a delegation.

Note, because there is no exclusive lock held between different subpools
when processing transactions, it's totally possible the SetCode transaction
and blob transactions with conflict sender and authorities are accepted
simultaneously. I think it's acceptable as it's very hard to be exploited.

[lightclient]

This approach LGTM. I see how you mean that it is a bit weird exposing the HasPendingAuth. One nice benefit of the way you've done this is that we don't need to additionally track all the auths using the reserver. This was my original approach and it ended up being quite tricky reserving and unreserving the authorities, so this minimizes the surface for issues there. Additionally, since we want to still allow 1 in-flight tx in the blob pool from accounts with pending delegations to avoid a deadlock in the account, it is going to be necessary to expose some legacy pool details to the blob pool.

[rjl493456442]

@lightclient Please take another look

[lightclient]

LGTM - I made a small change on the Reserver so that it will not require each use of Hold and Release to also include the pool name. Please take a look at it and the naming and let me know if you think it's okay.

[rjl493456442]

LGTM @lightclient !