Move module.go methods deprecated by RegisterServices into an extension interface

[ValarDragon]

Summary

Currently, all modules in Cosmos have to pay the complexity of legacy code, by defining functions in the module.go that only made sense with legacy API's. (Adding to the overall boilerplate of the codebase)

I propose we move Route(), QuerierRoute(), LegacyQueryHandler() into their own extension interface for the module.go. Perhaps:

type LegacyRegisterServices interface {
  AppModule
  Route()
  QuerierRoute()
  LegacyQueryHandler()
}

Then any legacy code that uses this, can attempt to run-time typecast the module to get these routes / handlers. Similarly, we can then delete these 3 methods off of every legacy module's module.go. (Thereby eliminating more boilerplate from every module)

This should be a non-breaking change for module developers, unless they do things off of the Module interface (and this legacy code), which I don't expect is true.

If folks agree with this, is this something that could get into a point release? If so, it would then enable us to start deleting these lines from tooling / existing chain codebases once they update to the relevant SDK version.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[alexanderbez]

TBH we've been removing the legacy APIs from AppModule, there is no need to further support or tweak legacy code that is meant to be outright removed. We already removed RegisterRESTRoutes (See: #11797)

[ValarDragon]

Gotcha. Its unclear to me what the API stability guarantees of these methods are, if they can just be deleted then happy about that!

[tac0turtle]

should we sneak this into 0.46?

[alexanderbez]

Gotcha. Its unclear to me what the API stability guarantees of these methods are, if they can just be deleted then happy about that!

Yes, the idea is that they're just deleted. In fact, we should delete whatever else is deprecated/legacy. @facundomedica is that something you're interested in? @ValarDragon pointed out the methods in the original issue body.