GRPC query refactor

[ValarDragon]

Background

Right now, the grpc query interface we have seems untenable to me:

• Mixes generic query logic and grpc-specific query logic
• Grpc query test logic is super ad hoc / mostly unnecessary looking
• Too much direct store handling
• Mostly boilerplate that could just get generated

This manifests in our codebase as problems with:

• Bad golang client interfaces (see every simulation PR, and all CLI code)
• Mixing of responsibilities at the grpc_query file logic, and therefore bad tests
• Increased complexity of Keeper packages

Suggested Design

• [ ] Move all grpc_query logic into client/grpc in every module, and these should only use generic keeper methods
• [ ] Have stable, simple methods for queries in the keeper package
  • A measurable outcome of this is that every packages simulation package should have 0 store package references.
• [ ] Make a YML descriptor file for query logic that we codegen the entire client/grpc folder from
  • All the logic should really be boilerplate, of "run Keeper function, run through a pagination function, package into proto response"\
  • This is maybe excessive, should be explored more.

Acceptance Criteria

• [ ] No grpc_query files in keeper package
• [ ] Simulation message creation no longer needs to directly access the store
• [ ] Some understanding of how to reduce overhead of our grpc client creation.

[vuong177]

Hi @ValarDragon is this being worked on? Can I try doing this task ?

[ValarDragon]

Good idea, though I think we may want to do this via AUtoCLI. Going to close for now