add hard-fork config for intg-tests

[ghost-not-in-the-shell]

Explain your changes: This PR adds fork config for every integration tests. The state_hash and global_slot and length were all directly taken from the mainnet database.

Explain how you tested your changes: *

Checklist:

• [ ] Dependency versions are unchanged
  • Notify Velocity team if dependencies must change in CI
• [ ] Modified the current draft of release notes with details on what is completed or incomplete within this project
• [ ] Document code purpose, how to use it
  • Mention expected invariants, implicit constraints
• [ ] Tests were added for the new behavior
  • Document test purpose, significance of failures
  • Test names should reflect their purpose
• [ ] All tests pass (CI will check this if you didn't)
• [ ] Serialized types are in stable-versioned modules
• [ ] Does this close issues? List them

• Closes #0000

[ghost-not-in-the-shell]

!ci-nightly-me

[ghost-not-in-the-shell]

!ci-build-me

[ghost-not-in-the-shell]

!ci-nightly-me

[ghost-not-in-the-shell]

!ci-nightly-me

[ghost-not-in-the-shell]

!ci-build-me

[ghost-not-in-the-shell]

!ci-build-me

[ghost-not-in-the-shell]

!ci-nightly-me

[ghost-not-in-the-shell]

!ci-build-me

[ghost-not-in-the-shell]

!ci-nightly-me

[ghost-not-in-the-shell]

!ci-build-me

[ghost-not-in-the-shell]

!ci-build-me

[ghost-not-in-the-shell]

ci-nightly-me

[ghost-not-in-the-shell]

!ci-nightly-me

[ghost-not-in-the-shell]

!ci-build-me

[ghost-not-in-the-shell]

!ci-build-me

[ghost-not-in-the-shell]

!ci-nightly-me

[nholland94]

Can you explain the motivation for this? It seems that this would eliminate the integration tests ability to test the case where networks don't have a fork config. I would expect that we run some tests with as if the network was a hardfork network, and some tests as if the network wasn't a hardfork network, but not to do one or the other universally across tests.

[ghost-not-in-the-shell]

Can you explain the motivation for this? It seems that this would eliminate the integration tests ability to test the case where networks don't have a fork config. I would expect that we run some tests with as if the network was a hardfork network, and some tests as if the network wasn't a hardfork network, but not to do one or the other universally across tests.

Since the berkeley network itself would be a hard fork against the mainnet, so we want the integration tests to be closer to the actual conditions of which we deploy the network. That's why I added a hard fork config to all the integration tests.

[nholland94]

Since the berkeley network itself would be a hard fork against the mainnet, so we want the integration tests to be closer to the actual conditions of which we deploy the network. That's why I added a hard fork config to all the integration tests.

We should still keep some integration tests on the non-hard-fork workflow, as we will continue to make non-hard-fork networks for testing purposes, and we don't want to break that workflow. If we have all integration tests testing the fork config workflow, we lose surface area into the non-hard-fork workflow in CI.