Lightclient module structuring and internal keeper usage

[damiannolan]

Summary

Historically light client modules have had a very open ended code structure with most if not all code existing within package types or since ibc-go/v7 within the root of the lightclient module, e.g. package tendermint. Since https://github.com/cosmos/ibc-go/pull/5806 and decoupling client encoding from routing within ibc-go there is now a more unrestricted opportunity to provide more structure and code organisation to lightclient modules - as we do not rely on all functionality being tightly coupled with the client state type/interface implementation.

See: https://github.com/cosmos/ibc-go/pull/5806#discussion_r1523504060

Problem Definition

Currently, there is little to no code organisation within the majority of lightclient modules. The 08-wasm module contains a similar structure, reminiscent to that of a regular sdk module and has seen much improvements and benefits from the refactor linked above.

With the refactor we introduced an internal/keeper to 07-tendermint with intensions for this to be useful for things such as msg server execution, in particular governance authorised requests such as changing client state parameters.

Proposal

Explore some paths for providing a simple and organised structure for lightclient modules.

• Using internal/keeper for state management. For example, usage of storeProvider for get/set operations of client/consensus states and metadata.
• Ideally keepers could be internal, but maybe they do not need to be.
• Maybe types such as client state and consensus state should be moved back to package types as they were previously.

---

For Admin Use

• [ ] Not duplicate issue
• [ ] Appropriate labels applied
• [ ] Appropriate contributors tagged/assigned

[DimitrisJim]

Nice! In addition, a re-org like this would also be a great op for an internal pkg for all the types that might now need to be exported (if we split each light client into multiple go pkgs)