Add storeutil module

[mslipper]

Hey all!

Was chatting with @alessio, and he mentioned that extracting these helper methods from the dex-demo repository into this one would be helpful for the ecosystem. These utilities make it easier to get and set data in a KVStore, and provide a framework for incrementing and getting integer sequences from a KVStore in order to mimic a primary key in SQL.

[tac0turtle]

im not sure if this constitutes as a module. @fedekunze @alexanderbez would you guys want this in the sdk instead of here?

[alessio]

This should be proposed as an addition to @cosmos/cosmossdk

[alexanderbez]

Somethings from incubator/storeutil/keys.go might have a place in types/, but that's it I think. ID auto-incrementing is very specific to the application and the SDK makes no use of IDs. Also, we can no longer provide a generic concrete codec as we're moving to protobuf.

[alessio]

See cosmos/cosmos-sdk#5491 for more information @mslipper

[alessio]

@alexanderbez do you suggest to put this on hold until the protobuf PR is merged?

ID auto-incrementing is very specific to the application and the SDK makes no use of IDs.

Yes, the SDK per se makes no use of it, though it'd be used by other applications out there. It'll be surely used by the dex modules we're planning to import in this repo. We factored this out of the dex-demo repo are prepared it for an inclusion proposal into the SDK.

@mslipper either way this should not be a module. This should be proposed as storeutil package at the root of cosmos-sdk.

[alexanderbez]

It would just seem strange to have logic around sequential IDs in types/ where the SDK makes no use of them. If an application needs it, why not just have the app define them in a package?

[sunnya97]

I think we need a place in the SDK to store a repository of common store access patterns.

Using sequential IDs is a one that is common. Btw, we do use it in governance, for the proposalIDs. It's also used in CosmWasm for codeID and contractID.

Another one is time queues (for example, the unbonding and redelegation queues in staking and the deposit period and voting period queues in governance).

I think it will be very useful for having this standard in the SDK somewhere, so each module writer doesn't keep rewriting these common patterns.

[alexanderbez]

That's reasonable @sunnya97. We have a types/ pkg for this but that's already becoming bloated and not really idiomatic go. We have store/ where this is more applicable 👍

Feel free to make a PR against the SDK @mslipper. I'll be closing this PR.

[alessio]

We have store/ where this is more applicable

@mslipper and I are more than happy to drop this into the store package. I'd just avoid to create another sub-package, what do you think? storeutil seems to be a bit more Go idiomatic than creating another util package - which it generally less idiomatic.