Integrate module to module IBC messages

[Kayanski]

This PR aims at allowing module-to-module ibc message passing via Abstract.

Depends on fix/callbacks (Removing user callbacks)
Depends on #329
Depends on #327

More details here Abstract IBC Module Interaction ADR

There are tests for a basic use case and for simple security issues

Closes ABS-351

Api Additions

• Added new IBC Client endpoint for module-to-module interaction

  ModuleIbcAction {
    host_chain: String,
    source_module: InstalledModuleIdentification,
    target_module: InstalledModuleIdentification,
    msg: Binary,
    callback_info: Option<CallbackInfo>,
  }

  This allows any source_module to send any msg to any other target_module on a remote host_chain and optionally awaiting a callback when the IBC message is executed (or failed).

• Added a new execute msg on the ibc host, only callable by the polytone proxy :

  /// Allows for remote execution from the Polytone implementation on a local module
      ModuleExecute {
          source_module: InstalledModuleIdentification,
          target_module: InstalledModuleIdentification,
          msg: Binary,
      },

• Added a module_ibc endpoint for modules to be able to receive module-to-module messages. This endpoint is only callable by the IBC-host on the chain. As the ibc-host is never installed on accounts, even apps need to go through version control directly to query the module reference to verify the sender.

Other code

• The IBC client is responsible to make sure source_module correspond to the message sender Implementation

• The Ibc Host propagate the message to the target_module by resolving it against version control and the eventual account passed

• Added IBC host to the registered Abstract modules inside version control
  (needed for apps to be able to query the ibc host address)

• Use current version instead of latest for client and host addr verification.

• Only allow same-account module interactions when account id is important for module identification (apps, standalone)

Details on InstalledModuleIdentification

This structure is needed to be able to indentify apps and standalone (modules that have a contract address that depends on the calling account).
This is not used in the case of an adapter.
A better impl could be the following:

pub enum InstalledModuleIdentification{
  App{
   account_id: AccountId,
   module_info: ModuleInfo
  },
  Standalone{
   account_id: AccountId,
   module_info: ModuleInfo
  },
  Adapter{
    module_info: ModuleInfo
  }
}

But this feels weird, when resolving ModuleInfo, one still has to make sure the module type is respected. So not sure what to choose there

Checklist

• CI is green.
• Changelog updated.

[cloudflare-workers-and-pages]

Deploying abstract-docs with    Cloudflare Pages

Latest commit:	f9e778a
Status:	✅  Deploy successful!
Preview URL:	https://e3c268fe.abstract-docs.pages.dev
Branch Preview URL:	https://feature-module-ibc.abstract-docs.pages.dev

View logs

[CyberHoward]

Could you elaborate on why there should be an extra endpoint for this?

I thought we could just call the module from the ibc-host without an extra endpoint as the ibc-host is the owner of the IBC account so it has all the privelages it needs.

However, this endpoint could be unique in that it should enable the developer to trust some computation on a different chain.

I almost question if this shouldn't be its own module type because for this type of application you would even want the configuration of the instances of the module to be protected from being changed by anyone other than the module itself.

So the notion of an "admin" would only be valid for the "hub" instantiation of the contract while the spokes are controlled by the "hub" instance.

This, and other logic/state could be useful to have in its own base package. ibc-app?

It also makes the possibility to have duplex communication between these applications very interesting. Essentially this is a first step towards mesh multi-chain applications.

I think my main feedback right now is that, if we do this as a different endpoint, the permission structures that we currently have need to be re-considered. If we don't "nerf" the ability for any module to perform admin-actions on a remote account then having a seperate endpoint isn't that valuable imo.

If we can somehow ensure that the state of a remote account can only be altered by the owner of the local account, and not by any modules installed on that account, then I think this route becomes more interesting as it allows for siloed communication that can't be tampered with by other modules installed on the account.

Would love to have a call on this to ideate it out more. Ideally with some notion doc :)

[CyberHoward]

Discussion here: https://www.notion.so/abstract-money/IBC-Module-Interactions-cf839655ef2a44e58efd1323668fbeb2?pvs=4

[Buckram123]

Look pretty good, few last concerns

• About preventing installed module to execute action from account. Idk if it makes sense, because installed module already can send pretty much any cosmos message from the account
• It feels like it shouldn't be enabled by default for every app and adapter, and will make unnecessary wasm bloat for most of the application, can we somehow generate module ibc handler only when it's used?

[Buckram123]

LGTM. Lets battle-test it to see if we get more ideas on refining it!

[Kayanski]

Look pretty good, few last concerns

* About preventing installed module to execute action from account. Idk if it makes sense, because installed module already can send pretty much any cosmos message from the account

* It feels like it shouldn't be enabled by default for every app and adapter, and will make unnecessary wasm bloat for most of the application, can we somehow generate module ibc handler only when it's used?

Thanks for the review !

On the bloating part, the endpoint has maybe 20 lines in total if it's not used by any handler (just like ib callback). I'm not sure it's what we can call 'bloat' here