refactor(reexcute/c): generic VM reexecution

[RodrigoVillar]

Why this should be merged

As part of #4108, this PR allows for generic VM reexecution by refactoring the reexecute/c package to only include C-Chain related logic, and migrates all other code to the reexecute package.

An example of how other VMs can utilize this refactored code for their reexecution tests is #4458, which adds reexecution tests for the P-Chain.

How this works

• Uplifts the VMExecutor and extends it by integrating the block channel and consensus metrics into it.
• Adds a NewMainnetVM() constructor to facilitate creating/initializing mainnet VMs (such as the EVM and PlatformVM).
• Uplifts StartServer() and StartCollector()
• Uplifts ExecuteBlockRange()

How this was tested

CI

Need to be documented in RELEASES.md?

No

[RodrigoVillar]

@copilot Can you do a code review similar to the review that you would do if I marked this PR as ready for review?

Update: this failed miserably.

[Copilot]

@RodrigoVillar I've opened a new pull request, #4452, to work on those changes. Once the pull request is ready, I'll request review from you.

[RodrigoVillar]

Example of metrics working from the latest CI run (ref):

[Copilot]

Pull Request Overview

This PR refactors the reexecution test infrastructure to support generic VM reexecution by extracting common logic from the C-Chain specific package into a reusable reexecute package. This enables other VMs (like P-Chain) to leverage the same reexecution testing framework.

Key changes:

• Moves VMExecutor, block channel creation, and consensus metrics from tests/reexecute/c to the generic tests/reexecute package
• Introduces NewMainnetVM() constructor for creating mainnet-configured VMs with standardized initialization
• Uplifts metrics server and collector utilities to the shared package

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
tests/reexecute/vm_executor.go	New file containing the generic VMExecutor implementation with block execution logic, mainnet VM initialization, and consensus metrics
tests/reexecute/metrics.go	New file with uplifted StartServer and StartCollector functions for Prometheus metrics handling
tests/reexecute/export.go	New file with ExportBlockRange function for copying blocks between LevelDB directories
tests/reexecute/c/vm_reexecute_test.go	Refactored to use the new generic reexecute package, removing C-Chain specific implementations

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Elvis339]

Quality work on this.

I've been looking at the C-chain and P-chain test files, and I'm noticing they're mostly identical. Both have the same flag definitions, similar TestMain setup, identical metrics server/collector logic, and the same database initialization pattern. The main differences are really just:

• Which VM factory to instantiate
• How to extract genesis bytes
• Metrics prefix (avalanche_evm vs avalanche_p)
• C-chain's predefined configs vs P-chain not having any
• Different Grafana dashboard paths

I wonder if could we can reduce the boilerplate? Something like having a single tests/reexecute/benchmark_test.go that accepts a --chain flag, and then dispatch to chain-specific configuration objects?

I'm imagining something like:

type ChainConfig interface {
    CreateVMFactory() vms.Factory
    GetVMParams(configBytes []byte) VMParams
    MetricsPrefix() string
    DashboardPath() string
    DefaultLabels(networkUUID string) map[string]string
    // Chain-specific metrics reporting
    ReportMetrics(b *testing.B, gatherer prometheus.Gatherer, elapsed time.Duration)
}

A few questions I'm curious about:

• What's the reasoning for keeping separate test files? Is there an anticipated need for chains to diverge significantly in their test structure? Or is this more about package organization?
• How do you see this evolving when we add more chains? If someone wants to add X-chain or subnet VM reexecution, would they copy-paste another test file, or is there a better path?
• Config handling - C-chain has this nice system with predefined configs (default/archive/firewood). Should this be part of the abstraction, or intentionally kept C-chain specific? What happens if P-chain or other chains need similar configurability?

We could eliminate duplication per chain by having one test file, and make adding new chains as simple as implementing the interface and registering it. But I'm also aware there might be reasons to keep things separate.

What do you think?