rpc: Significantly speedup debug_traceCallMany

[geomad]

Currently, when using the default value of transactionIndex (-1) in the debug_traceCallMany function, the state is obtained from the previous block and all the transactions are replayed.

This pull request retrieves the most recent state, resulting in a significant decrease in tracing time from 50-150 ms to just 1 ms.

I have tested the modification and it functions as intended. However, I kindly request you to review it, as I lack experience with the Go programming language and the client internals.

[AskAlexSharov]

1. Unlikely this change can work - because: if latest block = 10, and you re-exec transactions from this block - you need exec them on state 10-1, not on latests state (latest state already has changes made by block 10).

2. Seems this RPC method has no tests.
   To accept this PR:

• you or @hrthaowang (or somebody else) - please create another PR with tests. And maybe add link to some docs/spec.

3. Docs of this method: Request for a New RPC Endpoint eth_callMany #4471 - need copy docs fro github to source code.

[AskAlexSharov]

FYI: likely this PR will also improve speed: #7706

[AskAlexSharov]

• Unlikely this change can work - because: if latest block = 10, and you re-exec transactions from this block - you need exec them on state 10-1, not on latests state (latest state already has changes made by block 10).

• Seems this RPC method has no tests.
  To accept this PR:

• you or @hrthaowang (or somebody else) - please create another PR with tests. And maybe add link to some docs/spec.
  Docs of this method: Request for a New RPC Endpoint eth_callMany #4471 - need copy docs fro github to source code.

[geomad]

• Unlikely this change can work - because: if latest block = 10, and you re-exec transactions from this block - you need exec them on state 10-1, not on latests state (latest state already has changes made by block 10).

This scenario arises when the value of transactionIndex is not equal to -1. In this case, you aim to replay specific transactions within the block and perform the simulation afterwards.

On the other hand, when transactionIndex is equal to -1, it indicates that you want to include all the transactions in the block and conduct the simulation after all of them have occurred. This is where this PR comes into play. Instead of replaying all the transactions on top of state 10-1, we can simply extract the state from block 10 and exclude the replay of any transactions.

• you or @hrthaowang (or somebody else) - please create another PR with tests. And maybe add link to some docs/spec.
  Docs of this method: Request for a New RPC Endpoint eth_callMany #4471 - need copy docs fro github to source code.

Although I'm unsure if my expertise permits me to accomplish this, I might attempt it when I have some free time available if no one else is willing to undertake the task.

[AskAlexSharov]

This scenario arises when the value of transactionIndex is not equal to -1
I see. Then I agree.

In this case need:

• tests for both scenarios
• add docs (including this scenario)

[github-actions]

This PR is stale because it has been open for 40 days with no activity.

[geomad]

I tried to write some test for this but my experience doesn't allow it. Furthermore I couldn't find any existing tests, not even for trace.callMany to get a hang of it. if anyone wants to do it it would be cool. I have this change running one mont on my node and everything looks ok.

[github-actions]

This PR is stale because it has been open for 40 days with no activity.

[subtletech]

I believe this PR is rather a "bugfix" than an "improvement". In case transactionIndex is -1, TraceCallMany() must not replay all the transactions of the specified block on top of the state of the block previous to it. This is a major overhead, there are usually 100-200 transactions per block. Instead it must just pick up the state of the specified block.

This PR does not requre any tests and shoud be accepted without adding any.