feat: Add ORM package DO NOT MERGE!

[likhita-809]

ref: #9237

[codecov]

Codecov Report

Merging #9491 (3c2c426) into master (38d6702) will increase coverage by 0.31%.
The diff coverage is 82.21%.

@@            Coverage Diff             @@
##           master    #9491      +/-   ##
==========================================
+ Coverage   60.58%   60.89%   +0.31%     
==========================================
  Files         589      601      +12     
  Lines       37218    37769     +551     
==========================================
+ Hits        22548    23001     +453     
- Misses      12726    12787      +61     
- Partials     1944     1981      +37     

Impacted Files	Coverage Δ
orm/testsupport.go	48.57% <48.57%> (ø)
orm/genesis.go	50.00% <50.00%> (ø)
orm/auto_uint64.go	76.00% <76.00%> (ø)
orm/iterator.go	80.16% <80.16%> (ø)
orm/sequence.go	81.48% <81.48%> (ø)
orm/table.go	82.29% <82.29%> (ø)
orm/indexer.go	91.04% <91.04%> (ø)
orm/index.go	91.54% <91.54%> (ø)
orm/index_key_codec.go	100.00% <100.00%> (ø)
orm/orm.go	100.00% <100.00%> (ø)
... and 14 more

[robert-zaremba]

This can only be merged after RC candidate is out.

[alexanderbez]

Thanks for the contribution @likhita-809. This PR is pretty large. How do envision reviewers reviewing this PR effectively? Also, why are we adding an ORM to the SDK to begin with?

[likhita-809]

Thanks for the contribution @likhita-809. This PR is pretty large. How do envision reviewers reviewing this PR effectively? Also, why are we adding an ORM to the SDK to begin with?

This PR is just about migrating the ORM package from regen-ledger to cosmos-sdk.
As you can see in this discussion #9156 , this PR adds a new table-store (ORM) package which allows for automatic secondary index creation for data being stored by modules.
And also there is a proposal of Group module to be merged in SDK, which will need ORM to support it

[tac0turtle]

docs docs docs. Cant expect people to read the code to understand how to use this.

[aaronc]

@ryanchristo and @blushi will be coordinating to write-up docs.

I do think it would be ideal to split this up into smaller PRs if possible. One challenge is that all of this code already did go through a few rounds of review outside the SDK when we created the group module, so I understand the motivation to pull it in all at once. But still piece by piece is probably better.

What about putting this in the store/table package? I also think it could make sense for this package to have its own go.mod so we can move towards more modularity.

[aaronc]

Also, doing this piece by piece will allow us to make some upgrades to the initial version.

In particular, I'm thinking we might not want Tables and Indexes to hold direct references to StoreKeys anymore. This would allow us to declare those objects statically as vars which will be useful for #9158. Then the StoreKey would be provided together with the Context. What do you think @likhita-809 and @blushi ?

How about we start with a PR that just brings in the basic Table and Indexable functionality?

[blushi]

I believe that makes sense @aaronc

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[blushi]

@ryanchristo I believe we can keep this PR closed since it's just migrating the current version of the ORM package in one go and we don't wanna do that.