EPIC: Permissionless ICS

[insumity]

Problem

This is a meta issue to track the work of Permissinoless ICS. Permissionless ICS allows Opt In consumer chains to join ICS by simply issuing transactions, without having to go through a governance proposal.

Task list

Introduce new messages

Beta Give feedback

1. new MsgCreateConsumer and MsgUpdateConsumer messages

Re-key state

Beta Give feedback

1. change all messages by renaming chainId to consumerId and use accordingly but make sure the error mesasges point out that consumerId is now needed (e.g., all previously working MsgOptIn messages would now fail because there's no consumer chain with a stride-1 consumerId)
2. fix (and add new) unit/integration refactored to take into account consumerId instead of chainId
3. fix (and add new) E2E tests refactored to take into account consumerId instead of chainId

Introduce new state

Beta Give feedback

1. consumerId counter stores somewhere that is never recycled and always increments
2. (consumerId to chainId) needed for misbehavior evidence (e.g., HandleConsumerDoubleVoting)
3. (clientId to consumerId) to be able to find the right consumer chain when setting up a channel, etc.
4. potentially additional state for the phase of a consumer chain, e.g., whether it's registered, initialized, etc. so that instead of doing GetConsumerClientId( ...) to check if a chain has launched, we have something akin IsLaunched(...)
5. add owner_address for each consumer state

Deprecate proposals

Beta Give feedback

1. deprecate legacy consumer proposals. Specifically, deprecate ConsumerAdditionProposal which means getting rid of ConsumerAdditionProposals and using just the consumerIds instead that flow around (e.g., when checking which chain to launch) (see #2130)
2. deprecate MsgConsumerAddition and replace with a proposal that contains both MsgInitializeConsumer and MsgUpdateConsumer

Modify relayer (optional)

Beta Give feedback

1. contact Hermes to use the consumerId instead of the chainId for misbehaviour messages (see hermes#4153)
2. introduce query that given clientId returns the consumerId #2158
   needs-triage +1

Migrate

Beta Give feedback

1. migrate the state of already-launched consumer chains
2. make sure ongoing ConsumerAdditionProposals get migrated as well

Test

Beta Give feedback

1. think of test scenarios (similar to the Inactive Validators work - see docs/docs/adrs/adr-017-allowing-inactive-validators.md) and implement those (e.g., existing consumer chain keeps working, etc.)
2. give test scenarios to Hypha (i.e., things that could wrong, things to verify)
3. test all queries work with consumerIds if they used chainIds previously
4. verify we have checks on all the new fields that messages introduced (see here)

Write docs

Beta Give feedback

1. Write ICS docs here on Permissionless

Potpourri (so we do not forget)

Beta Give feedback

1. You should not be able to opt in to the different chains with the same chainId (add this in the ADR as well)
2. Search for TODO (PERMISSIONLESS) before cutting this
3. Thorough look on where chainID, chain ID, appear in code & comments, etc. and replace with consumer id
4. Stopping the chain before the evidence goes through might not allow us to slash in a permissionless setting. Think more on that. (At the end, we removed the state of a consumer chain only after an unbonding period of time)
5. Reduce duplicate code (see comment)
6. Potentiallly make the phases protobuf enums
7. (fix this) https://github.com/cosmos/interchain-security/pull/2172/files#r1731328299
8. Add invariants & simulation

Forge requirements (queries)

Beta Give feedback

1. Introduce a query to return the consumer valset before spawn time #2159
   scope: UI scope: provider +2
   
2. Permissionless: Introduce queries for retrieving consumer chains #2160
   +0