feat!: store the minimal power to be in the top N on EndBlock, instead of computing on-the-fly

[p-offtermatt]

Description

Closes: #XXXX

Compute the minimal power in the top N on EndBlock, when we compute it anyways for sending VSCPackets.

This should, at worst, delay the ability to opt out by an epoch
(intuitively, when someone is allowed to opt out not because their own power decreases, but because others powers increase, they would still compare against the old, stored MinPowerInTopN and not be allowed to opt out.
This would be solved after the epoch ends and the MinPowerInTopN is updated, however.)

NOTE: Needs a migration; the MInPowerToOptIn needs to be initialized during the migration

---

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]

Thanks for the change.

I'm not in favor of adding this to PSS. I do not see the benefits (i.e., slightly faster query-ing and opting-out) trumping the slight additional complexity that this PR introduces (i.e., additional state and potentially opting-out delays).

[p-offtermatt]

Yeah. I think in particular this touches some core parts, so I'm a bit concerned with adding this so late. I'd say let's leave it out for now; this seems relatively easy to introduce later on, too, if we think it becomes important.