Add tracing by block logic for geth

[carterqw2]

Description

Previously blockscout when using geth (unlike other clients) would trace transactions one by one, using the debug_traceTransaction RPC endpoint, that would result in an excessive number of requests for blocks with big number of TXs and unnecessary load on archive nodes. After switching from the custom JS tracer to the callTracer it became possible to use debug_traceBlockByHash or debug_traceBlockByNumber endpoints. This PR cherry-picks the following upstream commits: bc30e000f084819717072d66714143a85f96c117 and 4c2c9e32bed801a98a53bc4bfa0851ad761515cf that enable block tracing instead of individual TX tracing for geth.

Other changes

No.

Tested

Tests included in the commit. Tested locally with rc1staging env.

[github-actions[bot]]

Unit Test Results

       5 files  ±0     363 suites  ±0   3m 39s :stopwatch: +10s 2 636 tests ±0  2 562 :heavy_check_mark: ±0  74 :zzz: ±0  0 :x: ±0  2 650 runs  ±0  2 574 :heavy_check_mark: ±0  76 :zzz: ±0  0 :x: ±0 

Results for commit 47bf6dd0. ± Comparison against base commit 7318e03f.

:recycle: This comment has been updated with latest results.

[rkachowski]

After deploying 178f8ec to rc1staging it looks like the ingestion of internal transaction drops significantly

indeed i'm not sure it's even indexing internal transactions anymore - the following query returns no records

select *
from internal_transactions
where transaction_hash in (select hash from public.transactions order by block_number desc limit 1000);

[carterqw2]

I've updated the blockchain client to match the upstream format in this PR, it's already deployed to rc1staging. I also updated the blockscout's code to match the previous expectations of having block hashes in internal transaction responses. I tested it locally, seems to be working. @rkachowski could you take another look please?

[rkachowski]

Hey @carterqw2 , this requires archive nodes to be deployed at 1fc347330 - correct?

[carterqw2]

Hey @carterqw2 , this requires archive nodes to be deployed at 1fc347330 - correct?

Yeah, I updated them on rc1staging for testing but not on other envs yet.