feat!: introduce epochs

[insumity]

Description

Closes: everything under #1516 (excluding #1651 - to be completed at a later stage).

Note that the changes in this PR have already been reviewed in previous PRs (#1660, #1668, #1676, #1672, #1684) that introduced those updates to the feat/epochs branch.

This PR introduces epochs. The high-level idea behind the implementation is that we keep a slice of validators ([]ConsumerValidator) that are currently validating in an epoch. Each ConsumerValidator contains the power the validator had at the beginning of the epoch on the consumer chain, as well as the consumer public key the validator had set at the beginning of the epoch. At the boundaries of an epoch, we compute the ValidatorUpdates we need to send to a consumer chain using the DiffValidators function. DiffValidators can compute the updates by checking if the power or/and the consumer public key have been modified since the last epoch.

This PR slightly modified the majority of integration and E2E tests because those tests usually where advancing the provider chain by one block to verify that VSCPackets were being sent. Because now we have epochs, one block advancements are not enough, and we have to advance by an epoch to verify that VSCPackets are being sent. Additionally note that we increased the signed_blocks_window parameter of consumer clients from 15 to 20, while min_signed_per_window remains 0.5, and correspondingly we increased invokeDowntimeSlash to wait 11 (> 20 * 0.5) blocks instead of 10 to guarantee that a slash action would be triggered.

For a reviewer, the main focus should be the code in validator_set_update.go file and specifically the DiffValidators function and the ComputeNextEpochValidators method and how those are used in relay.go. Also, another important component is on how the consumer genesis is created in proposal.go.

This PR also deprecates any KeyAssignmentReplacement-related code.

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• Included the correct type prefix in the PR title
• Added ! to the type prefix if the change is state-machine breaking
• Confirmed this PR does not introduce changes requiring state migrations, OR migration code has been added to consumer and/or provider modules
• Targeted the correct branch (see PR Targeting)
• Provided a link to the relevant issue or specification
• Followed the guidelines for building SDK modules
• Included the necessary unit and integration tests
• Added a changelog entry to CHANGELOG.md
• Included comments for documenting Go code
• Updated the relevant documentation or specification
• Reviewed "Files changed" and left comments if necessary
• Confirmed all CI checks have passed
• If this PR is library API breaking, bump the go.mod version string of the repo, and follow through on a new major release

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• confirmed the correct type prefix in the PR title
• confirmed ! the type prefix if the change is state-machine breaking
• confirmed this PR does not introduce changes requiring state migrations, OR confirmed migration code has been added to consumer and/or provider modules
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage

[insumity]

This was changed from < to <= because otherwise the compatibility test for v4.0.0 would get the default test configuration that contains the blocks_per_epoch parameter and fail with:

startChain: Error: failed to validate genesis state: failed to unmarshal provider genesis state: unknown field "blocks_per_epoch" in types.Params

[p-offtermatt]

Some nits, and one concern: Wasn't there a plan to get rid of the maximum number for BlocksPerEpoch? Is there a reason to leave the (currently very conservative) upper limit?

[p-offtermatt]

wasn't there a plan to get rid of the maximum/make it much larger?

[insumity]

I'm in favor of keeping this upper limit. It just adds an additional check that in the best case will never be used and in the worst case will prevent from a potential bogus parameter.
Also, I do not believe that it is a very conservative upper limit. If the time we need for a block to be committed drops to something less than 6 seconds, then nothing bad will happen besides sending a greater number of VSCPackets. However, if the time to commit blocks increases (e.g., to 1 minute) then 1200 blocks correspond to 20 hours. If we add to this a potential multi-hour upgrade delay, then we might start having "unbonding pausing" issues with Neutron that has an unbonding period of 20 days.

We could get rid of this upper limit if we also looked at the BFT times when deciding when to send a VSCPacket, but this is not something we currently do, so I feel keeping an upper limit here is justified.

[p-offtermatt]

imo, it seems silly to me that, if for some reason we can't think of yet governance wants the parameter greater than 1200 blocks, there would first have to be an upgrade to Gaia itself before it could be done. keep in mind that for any param changes, there will need to be a vote anyways. I would recommend just giving clear guidance on appropriate values for the param in the docs instead of having the cap

[insumity]

I just the removed the upper limit.

[sainoe]

LGTM