Align minCompatibleTime settings across TestNetwork and Network

[michaelkaplan13]

Why this should be merged

Aligns TestNetwork compatibility with the Network created for full AvalancheGo nodes here. This should be updated in the future when required network upgrades are scheduled.

How this works

Passes the full UpgradeConfig to NewNetwork such that all callers (currently just node.go and test_network.go will use the same upgrade as the minimum compatible timestamp. This reduces the number of places where changes need to be made for each network upgrade in order to have Network instances be compatible.

It also results in the min compatible time of the TestNetwork being bumped to the FortunaTime.

How this was tested

N/A

Need to be documented in RELEASES.md?

No

[cam-schultz]

Could we instead remove minCompatibilityTime from NewNetwork altogether, and use FortunaTime in all instances? That way the activation time used by the test network is covered by general Network upgrade tests (i.e. e2e tests that run full nodes).

[michaelkaplan13]

Could we instead remove minCompatibilityTime from NewNetwork altogether, and use FortunaTime in all instances? That way the activation time used by the test network is covered by general Network upgrade tests (i.e. e2e tests that run full nodes).

I debated that, or adding the minCompatibleTime to the upgrade.Config somehow, so that nothing in the Network code needs to be changed for future network upgrades.

I think the minCompatibleTime can be defined as the time of the next scheduled network upgrade activation or, if there are no scheduled upgrades in the future, the time the last network upgrade activated.

Either way, I agree minimizing the number of places updates need to be made should be the goal in order to reduce the chance that any are missed in the future.

[michaelkaplan13]

Could we instead remove minCompatibilityTime from NewNetwork altogether, and use FortunaTime in all instances? That way the activation time used by the test network is covered by general Network upgrade tests (i.e. e2e tests that run full nodes).

I updated the PR to this approach now. I agree it's less error prone since there's only one place where the minCompatibleTime is defined, and should be covered in the E2E tests. The downside is needing to pass the full upgrade.Config to NewNetwork, and the minCompatibleTime definition being embedded in the implementation is harder to find.

I'm pretty indifferent between the options myself really, open to everyone's input.

[github-actions]

This PR has become stale because it has been open for 30 days with no activity. Adding the lifecycle/frozen label will cause this PR to ignore lifecycle events.