chore: loosen assertions in SetOrderBeginBlockers() and SetOrderEndBlockers()

[0Tech]

Description

Thanks to #12603, we can omit the methods BeginBlock() and EndBlock() from a module. This patch goes one step further, allowing one not to add the module name into SetOrderBeginBlockers() or SetOrderEndBlockers() if the module does not have the corresponding method.

Before implementing the method, we cannot know its order in the modules, so I think it would be better not to add a module into the order list before implementing it.

---

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 API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building 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

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 ! in the type prefix if API or client breaking change
• 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
• manually tested (if applicable)

[0Tech]

I provide the supplementary comments.

[0Tech]

Because the main reason of the PR is to make the list clean, I removed module names which does not have BeginBlock().
But, it's not mandatory.

[0Tech]

The assertion passes if the module does not have BeginBlock().

[0Tech]

The relevant unit test case.

[tac0turtle]

This is nicer but the reason we added it before was that a developer forgot to add the begin blocker and it caused issue. I think we should keep that functionality but instead, if possible, we should check all the modules if they have the interface(s) somewhere else, if so then error out telling the user they forgot to add a module this prevents the problem we faced earlier but without forcing users to list all the modules

[0Tech]

a developer forgot to add the begin blocker

You mean, the developer forgot to add the module name into the argument of SetOrderBeginBlockers(), right?

This is nicer but the reason we added it before was that a developer forgot to add the begin blocker and it caused issue. I think we should keep that functionality but instead, if possible, we should check all the modules if they have the interface(s) somewhere else, if so then error out telling the user they forgot to add a module this prevents the problem we faced earlier but without forcing users to list all the modules

I thought following procedures are necessary:

• register the modules which we are going to use
• specify the order of BeginBlock() and EndBlock()

Hence, while sequencing them, we can also check whether the modules which have BeginBlock() (or EndBlock()) are not specified in the list. This is the intention of this PR.

If a module has BeginBlock() and one forgets to add the module into SetOrderBeginBlockers(), it will still panic.

[julienrbrt]

lgtm! It seems like a nice improvement!

Have you checked it the docs (docs/) are up to date?

I think we should add a changelog under improvements too.

[likhita-809]

lgtm