Planning: Add parameters to Network::Testnet variant

[arya2]

Zebra currently hard-codes some consensus parameters that would be useful to change for testing.

The original plan was to add a NetworkParameters struct with fields for overriding the default hard-coded parameters that were needed to Network::Testnet.

It may be better to add an empty NetworkParameters struct to Network::Testnet as a first step, then follow up by adding a field for the network upgrade activation heights or other parameters as a separate issues.

[teor2345]

I suggest we do this in more stages, because some of these changes will be large PRs by themselves:

1. refactor tests to use is_mainnet() to look up test vectors using new functions in zebra-test, rather than matching on Testnet. This should be quick and easy to approve since it's only test code, and there are only mainnet and default public testnet test vectors. (No custom testnet vectors.)
2. refactor production code that matches on Testnet to use a new Network method for each consensus rule. We can't use is_mainnet() or is_default_testnet() for consensus rules, because we might have custom testnets with mainnet parameters, or parameters that are different from both mainnet and testnet.
3. Add an empty NetworkParameters struct to Testnet, and deal with any missed Testnet matches in the same way as steps 1 or 2. Do an automated search for any Mainnet matches in production code, and deal with them in the same way. (This can be done by changing the variant name in the module, and running a production build, then changing it enough to get each crate to build.)
4. Pause and check which fields we want to add to NetworkParameters, and how important this work is, based on what we've learned from these PRs, and the progress of other teams.

For more details about these code changes, see my review of the original PR.

I suggest we do it this way because:

1. This is a high-risk area of the code, because it deals with the fundamentals of our consensus rules.
2. The original PR was too large to test or review accurately.
3. It's easier to modify and review test code in a separate PR.
4. If we start using is_mainnet() or is_default_testnet() methods in production code, that code will silently develop consensus bugs whenever we add a relevant network parameter.
5. We're going to learn a lot from this process, so if we plan too far ahead, those plans will become outdated.

The potential drawbacks are:

1. This process could be slower than changing everything at the same time (or it could be faster)
2. There might be a more minimal way of doing this change, while still creating an API that's easy to use correctly.

What do you think? Is there anything missing, or any scope that could be cut?

[AloeareV]

"For more details about these code changes, see my review of the original PR." What's the original PR referenced here?

[AloeareV]

Oh, I found a link to the pr #7924 in the issue version of this

[arya2]

I suggest we do this in more stages, because some of these changes will be large PRs by themselves:

Okay, agreed and added to the issue.

What do you think? Is there anything missing, or any scope that could be cut?

I think this is perfect for now.