feat(delayedack): paginate rollapp packets when deleting them

[zale144]

Description

• When deleting rollapp packets each epoch end, instead of fetching all of them at once, we apply batching now, to prevent unbounded memory usage.
• The upgrade handlers are refactored so that they use an interface for the upgrades themselves, keepers are extracted to be in a separate package.

---

Closes #320

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.

PR review checkboxes:

I have...

• [ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• [ ] Targeted PR against the correct branch
• [ ] included the correct type prefix in the PR title
• [ ] Linked to the GitHub issue with discussion and accepted design
• [ ] Targets only one GitHub issue
• [ ] Wrote unit and integration tests
• [ ] Wrote relevant migration scripts if necessary
• [ ] All CI checks have passed
• [ ] Added relevant godoc comments
• [ ] Updated the scripts for local run, e.g genesis_config_commands.sh if the PR changes parameters
• [ ] Add an issue in the e2e-tests repo if necessary

SDK Checklist

• [ ] Import/Export Genesis
• [ ] Registered Invariants
• [ ] Registered Events
• [ ] Updated openapi.yaml
• [ ] No usage of go map
• [ ] No usage of time.Now()
• [ ] Used fixed point arithmetic and not float arithmetic
• [ ] Avoid panicking in Begin/End block as much as possible
• [ ] No unexpected math Overflow
• [ ] Used sendCoin and not SendCoins
• [ ] Out-of-block compute is bounded
• [ ] No serialized ID at the end of store keys
• [ ] UInt to byte conversion should use BigEndian

Full security checklist here

----;

For Reviewer:

• [ ] Confirmed the correct type prefix in the PR title
• [ ] Reviewers assigned
• [ ] Confirmed all author checklist items have been addressed

---;

After reviewer approval:

• [ ] In case the PR targets the main branch, PR should not be squash merge in order to keep meaningful git history.
• [ ] In case the PR targets a release branch, PR must be rebased.

[danwt]

Closes what issue?

[zale144]

Biggest open question I have is, there are several calls to ListRollappPackets in our code and after this PR not all of them are batched with a limit

So why can't memory problems occur at one of those places?

The scope of this PR is to address the potential DoS when deleting the finalized and reverted packets

[danwt]

The task is really to fix the DOS, the one in after epoch is just an example. If you think it should be broken down into multiple PRs then create issues to fix the other places. I don't see why adding a limit to after epoch solves the problem when the grpc queries and FinalizeRollappPackets still do everything unlimited?

Also, some of the naming is still sloppy IMO and the keepers/ module is unwarranted

[zale144]

The task is really to fix the DOS, the one in after epoch is just an example. If you think it should be broken down into multiple PRs then create issues to fix the other places. I don't see why adding a limit to after epoch solves the problem when the grpc queries and FinalizeRollappPackets still do everything unlimited?

Also, some of the naming is still sloppy IMO and the keepers/ module is unwarranted

The FinalizeRollappPackets issue is tracked separately and will be addressed in another PR. For this one, it's just preventing out of bonds memory use.