Add `MsgServer` to interchain accounts controller

[damiannolan]

Summary

Add a new MsgServer to 27-interchain-accounts which exposes two distinct rpc endpoints:

• RegisterAccount
• SubmitTx

Problem Definition

The current design implemented in 27-interchain-accounts mandates that a base application referred to as an authentication module is developed in order to provide custom authentication as an entrypoint to interchain accounts. In this approach an application developer is expected to compose their base application (authentication module) with the ICS27 controllerKeeper and leverage the exported APIs exposed for account registration and sending of interchain accounts transactions.

Since the release of cosmos-sdk v0.46.x, the new design of x/gov and x/group allow for arbitrary message passing via the cosmos-sdk's MsgServiceRouter. When a proposal is accepted it allows the state machine to execute an arbitrary number of sdk.Msgs. Since this functionality has been introduced it has become clear that x/gov and x/group act as authentication modules with respect to interchain accounts integration.

Proposal

Introduce a new MsgServer to 27-interchain-accounts/controller and incrementally move towards deprecation of public APIs.
This allows for existing app developers to simply change their code from a public API (RegisterInterchainAccount / SendTx) call to message passing, whereby one would compose their app with the cosmos-sdk MsgServiceRouter and retrieve the handler appropriately based on the message typeURL, as is done in many existing modules such as x/gov, x/group as well as 27-interchain-accounts/host. This provides a more standardised approach to integrating with interchain accounts.

RegisterAccount

Introduce a new rpc endpoint RegisterAccount. This rpc should provide the existing functionality of the exported RegisterInterchainAccount function in 27-interchain-accounts/controller.

• Add RegisterAccount rpc and proto message definitions #2051
• Implement sdk.Msg interface for MsgRegisterAccount #2053
• Implement the rpc handler method for RegisterAccount #2055
• Add CLI for new ics27 RegisterAccount rpc #2061

service Msg {
  rpc RegisterAccount(MsgRegisterAccount) returns (MsgRegisterAccountResponse);
  ...
}

message MsgRegisterAccount {
  option (gogoproto.equal)           = false;
  option (gogoproto.goproto_getters) = false;

  string owner                      = 1;
  string connection_id              = 2 [(gogoproto.moretags) = "yaml:\"connection_id\""];
  string version                    = 3;
}

message MsgRegisterAccountResponse {
  string channel_id = 1 [(gogoproto.moretags) = "yaml:\"channel_id\""];
}

SubmitTx

Introduce a new rpc endpoint SubmitTx. This rpc should provide the existing functionality of the exported SendTx function in 27-interchain-accounts/controller.

• Add SendTx rpc and proto message definitions #2052
• Implement sdk.Msg interface for MsgSendTx #2054
• Implement the rpc handler method for SendTx #2056
• Add CLI for new ics27 SendTx rpc #2062

service Msg {
  ...
  rpc SubmitTx(MsgSubmitTx) returns (MsgSubmitTxResponse);
}

message MsgSubmitTx {
  option (gogoproto.equal)           = false;
  option (gogoproto.goproto_getters) = false;

  string owner                            = 1;
  string connection_id                    = 2 [(gogoproto.moretags) = "yaml:\"connection_id\""];
  InterchainAccountPacketData packet_data =  3 [(gogoproto.moretags) = "yaml:\"packet_data\""];
  ibc.core.client.v1.Height timeout_height = 4 [(gogoproto.moretags) = "yaml:\"timeout_height\""];
  uint64 timeout_timestamp = 5 [(gogoproto.moretags) = "yaml:\"timeout_timestamp\""];
}

message MsgSubmitTxResponse {
  uint64 sequence = 1;
}

---

For Admin Use

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

[damiannolan]

Requires discussion regarding usage of google.protobuf.Any in MsgSubmitTx. This requires that the message type submitted for execution on the host chain is registered on the controller chain interface registry.
The obvious solution is to use the InterchainAccountPacketData type directly, however this may be challenging from a ux perspective as the message would need to be constructed and proto3 encoded to []byte off chain.

Edit: discussed with @colin-axner and decided the best option is to go with InterchainAccountPacketData in favour of Anys for the payload in SubmitTx.
It's not a good design or sustainable to force chains to register msg types of various counterparties to allow nested Anys to be resolved. While its tricky from a client UX perspective wrt to CLI's, it would likely be a non-issue for use-cases which are actually fronted by something like a client web application, where they could handle encoding of different msg types which belong to many chains.

More context in this thread: #2086 (comment)

[robert-zaremba]

Great issue. Using Msg routing is the right approach. BTW, x/authz is also using this mechanism.

[robert-zaremba]

At first glance it makes sense to register messages in the controller chain for Any.

However, It may create burden if there is one chain to control many (it would need to register all custom messages and keep track with versions).