light-client: Type Generalization

[brapse]

This issue is a Refactor of #387 with the intention of being more actionable

Problem

The core types defined in the tendermint crate and used in the light-client crate are broad, complex and subject to change between versions of tendermint. This makes them difficult to generate during tests and cumbersome to integrate against. We want looser coupling between functions and types allowing our core logic to be robust against minor changes in the serialized form of data structures.

Goals

• Reduce the size of the dependency graph
• Have a clear mocking & testing strategy for core data types
• Have a clear migration path for tendermint core data structure changes

Ideal

• All of our data types are generic enough to be invariant to tendermint core data structure changes

Approach

This task is complex and should be broken down into several steps. It is likely that we will have to compromise between generality and developer economics. The first step is to produce an ADR outlining a potential strategy to navigating such a tradeoff.

[ebuchman]

I think we pretty much achieved all this with the traits in the original version, which are documented in ADR-02. Maybe would be helpful to first document the ergonomic challenges with that version, and if/how they might be overcome within the refactored structure.