Decouple auth/vesting

[alessio]

Decouple the vesting functionality from x/auth and create a new x/vesting module which extends x/auth functionality.

---

For Admin Use

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

[alexanderbez]

What are you plans here @alessio? A sub-package under x/auth?

[alessio]

Vesting types and functions should live either in a subpackage within x/auth or in a standalone x/vesting package. I have a slight preference for the latter - in my view if we manage to decouple completely it won't make much sense anymore to have in x/auth.

[alexanderbez]

I'd actually argue for the former is possible. I don't see that clear of a separation...they're nearly identical types apart from a few extra fields and methods.

[rigelrozanski]

Yeah this is purely out of style what we do or don't group sub-modules - I would argue because vesting relies heavily on the auth infrastructure, that it should be a subpackage of auth - but also there isn't really a problem with having it as a standalone module. kinda indifferent tbh

[alessio]

I'm fine with either really

[fedekunze]

I like the idea of a x/vesting module in case we want to extend the current vesting functionality. This could allow us to say create new vesting accounts on a live chain instead of defining them just on genesis

[alexanderbez]

It really depends on on the common ground between it and auth. Even with extending it, having it a sub-package could make more sense. Alternatively, it could just import x/auth and be a standalone package. Maybe that does make more sense.

[rigelrozanski]

So in that case - vesting-auth would effectively be extending auth and vesting-auth would be the module imported by the application

[alexanderbez]

Correct @rigelrozanski

[fedekunze]

@rhuairahrighairidh @karzak is the Kava team working on this issue?

[karzak]

Yes, I have a PR that's about ready. I will rebase it on #5017 and submit today/tomorrow.