Add ITraceDebugPlugin infrastructure

[devhawk]

This PR adds infrastructure to capture trace information during execution in order to enable Time Travel Debugging

[devhawk]

Note, build failure after 9c73550 is unrelated to code change. Github workflow was unable to download dotnet-format

[devhawk]

Note, TestReVerifyTopUnverifiedTransactionsIfNeeded passes locally and is not related to my code change as far as I can tell

[shargon]

Is not enough with GetSink ? it's needed ShouldTrace?

[devhawk]

The idea here is that you don't likely want to trace every tx. For example, if I deploy a contract to mainnet, I can also deploy a mainnet node with the debugger plugin to capture every run of my contract for later analysis if need be. But I don't want to capture every tx - just mine. This API allows me to cleanly separate the logic that decides if a given tx should be traced vs. the logic that does the tracing.

[shargon]

But this logic can be done in the plugin, if you don't want to trace this TX, just ignore it, isn't it?

[devhawk]

Yes, it could be done other ways. I feel this approach provides more flexibility in case we want to support multiple tracers for a single transaction.

[shargon]

What do you think @erikzhang ?

[erikzhang]

I think the only method that ITraceDebugPlugin should have is GetApplicationEngine(). It returns an object inherited from ApplicationEngine class. If no ITraceDebugPlugin is found, then the default ApplicationEngine is used.

And the ITraceDebugPlugin should be renamed to IApplicationEngineProvider.

[devhawk]

I think the only method that ITraceDebugPlugin should have is GetApplicationEngine(). It returns an object inherited from ApplicationEngine class. If no ITraceDebugPlugin is found, then the default ApplicationEngine is used.

And the ITraceDebugPlugin should be renamed to IApplicationEngineProvider.

@erikzhang Could you please provide more context around what your goal is with this design? I would like to understand your thinking better.

[erikzhang]

In this way, we can extend the ApplicationEngine in the plug-in at will. The solution in this PR feels that most of the functions of the plug-in are already in the core, and there is no scalability.

[devhawk]

FYI, I'm leaving this PR open for now, but #1758 is likely going to make this PR obsolete

[devhawk]

Closing in favor of #1758