[Relayminer] Query for on-chain session param `num_blocks_per_session`

[bryanchriswhite]

Summary

Refactors the relayminer to query for the current num_blocks_per_session each (or even multiple) time(s) it's used. This is a naive implementation to just get the relayminer using the on-chain param instead of the const that's still defined in the session keeper pkg but which will be removed in forthcoming work.

Next Steps

2. Implement ModuleParamsClient[P any] (see: notion - ModuleParamsClient).
3. Refactor sessionQuerier to use ModuleParamsClient[sessiontypes.Params] to avoid excessive querying.
4. ...

Issue

• 517

Type of change

Select one or more:

• [x] New feature, functionality or library
• [ ] Bug fix
• [x] Code health or cleanup
• [ ] Documentation
• [ ] Other (specify)

Testing

Documentation changes (only if making doc changes)

• [ ] make docusaurus_start; only needed if you make doc changes

Local Testing (only if making code changes)

• [x] Unit Tests: make go_develop_and_test
• [x] LocalNet E2E Tests: make test_e2e
• See quickstart guide for instructions

PR Testing (only if making code changes)

• [x] DevNet E2E Tests: Add the devnet-test-e2e label to the PR.
  • THIS IS VERY EXPENSIVE, so only do it after all the reviews are complete.
  • Optionally run make trigger_ci if you want to re-trigger tests without any code changes
  • If tests fail, try re-running failed tests only using the GitHub UI as shown here

Sanity Checklist

• [x] I have tested my changes using the available tooling
• [x] I have commented my code
• [x] I have performed a self-review of my own code; both comments & source code
• [x] I create and reference any new tickets, if applicable
• [x] I have left TODOs throughout the codebase, if applicable

---

:rocket: This description was created by Ellipsis for commit bf24e6c6d0e5199387598c891eacdf4c02d35e6b

Summary:

Refactors the relayminer to dynamically query the num_blocks_per_session parameter from the blockchain, updating relevant classes to utilize this new approach.

Key points:

• Refactor relayminer to dynamically query num_blocks_per_session.
• Update SessionQueryClient interface with new methods for session parameters.
• Implement new methods in sessionQuerier.
• Utilize new session parameter methods in relayerProxy and related classes.
• Prepare for future enhancements in session handling and grace period calculations.

---

Generated with :heart: by ellipsis.dev

[github-actions[bot]]

The CI will now also run the e2e tests on devnet, which increases the time it takes to complete all CI checks. If you just created a pull request, you might need to push another commit to produce a container image DevNet can utilize to spin up infrastructure. You can use make trigger_ci to push an empty commit.

[bryanchriswhite]

1. I'm not a fan of how many times GracePeriod is coming up in so many functions in the SessionQueryClient. The Session is a first class citizen, the Grace period is a hack for an edge case, but it's becoming a "first class citizen", which is NOT what we want.

Currently, SessionGracePeriod is in terms of sessions. It's being used to calculate various block durations / heights / offsets. If we rewrite it to be in terms of blocks, the need for #GetSessionGracePeriodBlockCount() goes away. However, I would also expect this to become a param at some point. If it does, then it will have to be queried and/or cached off-chain & retrieved from the multistore on-chain.

I would propose renaming it to SessionGracePeriodBlocks in the interim.

[bryanchriswhite]

@Olshansk I'm marking this as a draft for now. I think this will change now that we've decided to add the shared module. I may close and re-open this PR on a new branch or rebase this one.

[red-0ne]

@Olshansk

1. I'm not a fan of how many times GracePeriod is coming up in so many functions in the SessionQueryClient. The Session is a first class citizen, the Grace period is a hack for an edge case, but it's becoming a "first class citizen", which is NOT what we want.

I disagree on that, I see a healthy ratio of SessionEndBlockHeight/GracePeriod in this diff.

It is, one of the key times of the C&P life cycle just like Claim/Proof window submissions that will be almost as visible as soon as we start relying on them.

Although, I agree that the grace period is a bit special in the sense that it indicates when a session is no longer accepting new relays to it.

[bryanchriswhite]

:rotating_light: Do not delete this branch until #555 changes bases! :rotating_light: