feat: Add mempool drop checks to the provider heartbeat

[popzxc]

Motivation

Fixes #2678

Solution

Adds a period check to the heartbeat to check if transactions are still present in mempool.
This turned out to be more complex than I initially expected. Reasons:

1. We cannot distinguish a situation where transaction was dropped from a mempool from the situation where it didn't reach the mempool yet (and transaction could've been dropped before we started watching it).
2. We cannot rely on new blocks, because e.g. anvil won't mine new blocks without need by default.
3. We want this to be configurable, because some people might handle this kind of behavior by other means.

So I introduced configurable mempool check interval on the root provider. If it's not provided, we will set it to poll_interval * 10 (which seems to be a reasonable amount of time for transaction to appear in mempool). If it's provided and it's Some, we will use provided interval. For provided None, we will disable checks.

Heartbeat integration is pretty straightforward: for any unconfirmed transaction we remember when it was added to the watch list, and start checking it only after configured interval has passed.

cc @mattsse

PR Checklist

• Added Tests
• Added Documentation
• Breaking changes

[popzxc]

This change is technically breaking, as the enum is not marked with #[non_exhaustive], but I'm not sure what's the project policy in that case is.

[graphite-app]

There's a potential timing issue in the mempool check logic. Currently, last_mempool_check is updated after the async reap_mempool_wipes() completes, but the elapsed time check happens before starting this operation. If the mempool check takes significant time to complete, subsequent iterations might incorrectly skip checks because the elapsed time would include the previous check's duration.

Consider updating last_mempool_check before starting the async operation or adjusting the logic to account for the time spent in the async operation. This would ensure consistent check intervals regardless of how long each check takes to complete.

Suggested change

	if let Some(check_interval) = self.mempool_check_interval {
	if last_mempool_check.elapsed() >= check_interval {
	self.reap_mempool_wipes().await;
	last_mempool_check = Instant::now();
	}
	}
	if let Some(check_interval) = self.mempool_check_interval {
	if last_mempool_check.elapsed() >= check_interval {
	last_mempool_check = Instant::now();
	self.reap_mempool_wipes().await;
	}
	}

Spotted by Diamond

Is this helpful? React 👍 or 👎 to let us know.

[popzxc]

It's probably better to run these checks less often, in case e.g. some network request takes too long.

[mattsse]

this is likely a bit problematic for networks without a mempool, e.g. on op the tx is usually not retrievable until it was mined, because most providers dont maintain a mempool and strictly forward it

so this means we cant really rely on this behaviour

[popzxc]

Hmm, interesting. Do you have any ideas for a workaround?

I believe that we do need some kind of fix, because cast hanging indefinitely is not a good user experience, and in case of foundry we do need a generic solution. We can, in theory, analyze the chain ID to enable this when it's safe, but it doesn't feel right either.

[daweth]

This isn't just an issue in cast, but also with alloy-rs @mattsse especially for newer or exotic EVMs, has been extremely frustrating to deal with. If there's no way to monitor the mempool, I suppose the current behavior is fine, but if there is, the user should know