Fix for "transaction indexing is in progress"

[0xOmarA]

Summary

This PR fixes an issue that we've had in our differential testing framework where we would sometimes fail to get the transaction receipt of certain transactions and would instead get the error "transaction indexing is in progress" as can be seen in the following logs:

  2025-07-10T12:33:09.232936Z ERROR revive_dt_core::driver: Failed to execute transaction when deploying the contract on node : "revive_dt_core::Geth", "Callable", server returned an error response: error code -32000: transaction indexing is in progress, data: "transaction indexing is in progress"
    at crates/core/src/driver/mod.rs:245 on main ThreadId(1)
    in revive_dt_core::driver::Executing case with case: "first", case_idx: 0
    in retester::Running driver with metadata_file_path: "era-compiler-tests/solidity/complex/array_one_element/test.json"

  2025-07-10T12:33:09.232959Z ERROR revive_dt_core::driver: Leader deployment failed for Main: server returned an error response: error code -32000: transaction indexing is in progress, data: "transaction indexing is in progress"
    at crates/core/src/driver/mod.rs:415 on main ThreadId(1)
    in revive_dt_core::driver::Executing case with case: "first", case_idx: 0
    in retester::Running driver with metadata_file_path: "era-compiler-tests/solidity/complex/array_one_element/test.json"

Description

I have added a comment to the code that explains this entire issue that we have been having with "transaction indexing is in progress", but will also re-iterate it here in the PR description. The hope is that we would keep that comment in the code so that it's context for future us to know why we're doing getting the receipt in this way.

In Geth, before we can get a transaction receipt of a committed transaction, the transaction must be indexed first by the transaction indexer. The indexer runs in a separate process and therefore if a transaction is committed it doesn't necessarily mean that the transaction has been indexed and that we can get its receipt. Attempting to get the receipt before the indexer has indexed it returns the error: "transaction indexing is in progress". Some of the ecosystem tooling have deployed a fix for this in the form of retrying to get the receipt if the RPC method returns "transaction indexing is in progress".

In alloy, once it sees that a transaction has been confirmed it assumes that it has also been indexed and therefore they attempt to immediately get the receipt, which could fail as the indexer could still be running trying to index the transaction as seen here.

I have implemented similar logic to Web3.py in this PR where we retry getting the receipt if it fails with up to a maximum number of retries. If the receipt is found it's returned.

[xermicus]

Thanks!