Add migrations for solo machine protobuf types

[colin-axner]

Summary

Todo:

• add optional migrations feat: add optional migration pruning for tendermint consensus states #2800
• add automatic in-place store migrations feat: add automatic in-place migrations for 02-client-refactor (v7) #2819
• add genesis migrations feat: add genesis migrations for v7 #2824
• remove legacy migrations
• review documentation

---

For Admin Use

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

[colin-axner]

remove Allow boolean in solo machine client state as well

[colin-axner]

I did some initial work for this since the issue lacked sufficient information to get started. https://github.com/cosmos/ibc-go/tree/colin/1863-v7-migrations

What I have done:

• reused v1 to v2 consensus version migrations and renamed them to v2 to v3
• moved localhost migration to v2 to v3 migrations and made it automatic
• moved all migrations into 02-client/migrations/v7
• removed addition of metadata (used in v1 to v2)
• updated solomachine migration to be v2 to v3 proto definition
• simplified genesis migration

What's left?

• review tests/cleanup
• probably move localhost_test.go into store_test.go
• split tendermint pruning into separate migration function
• add logging

Note: It will not be possible to upgrade from stargate -> v7

[colin-axner]

Further thoughts:

Let's move tendermint expired consensus state pruning into an optional migration which chains can call directly. I like the idea of optimizations being optional and required migrations being automatic. Iterating over all clients/consensus states can actually take quite a bit of time (a year ago it took like an hour), so I think it makes sense to skip as automatic. It could also be reused during any upgrade. Only iterating over solo machine/localhost clients should be a lot faster!

Lets also add logging to the expired tendermint pruning. Might be nice to log the number of consensus states pruned. This can inform a chain whether it is worth running the migration or not since even if 2 consensus states are pruned, all consensus states will be iterated