eth/traces,core: support tracing transactions while the chain is synchronizing and store results in db.

[recursion128]

This PR supports the tracer running alongside the synchronization process when the chain is synchronizing normally, tracing transactions, and recording the trace results in the geth database.

It also allows users to configure the tracer, to support the persistence of different tracer results.

The main benefit of this modification is that when users call debug_traceTransaction, if the trace result of the transaction has already been persisted, it will be read from the database instead of replaying the transaction. This will significantly reduce the RPC delay and CPU usage. This is very beneficial for websites like Debank that rely on debug_traceTransaction for Portfolio tracing.

[rjl493456442]

I think it's duplicated with @s1na 's work

[recursion128]

@rjl493456442 I appreciate your reminder.I have looked at @s1na's PR(#27629). His work has set a new groundwork for tracer-related development. The implementation of the long-running tracer aligns with my PR, yet it seems to lack trace persistence. I'm contemplating further implementation based on his work.

[rjl493456442]

You store the tx trace result in key-value store directly, it will be huge overhead for the entire system.
We prefer to store block traces in the freezer, which is append-only flat files. I am not sure if sina already
had some implementations or not.

[s1na]

Hi @zhangguyu6. Very cool that you're working on this. I liked your code changes. I agree with @rjl493456442 that the persistence is still half-baked. I don't have any code on that. I'm waiting for #25963 to arrive since the mechanism used for storing state diffs is very similar to what we want for traces as well.

#27629 is the first step to the full feature which would include persistence and querying through RPC. If you wanted to coordinate you can find me on discord, my handle is @s1na.