Update abstract IBC implementation

[CyberHoward]

No description provided.

[codecov]

Codecov Report

Merging #290 (0638764) into main (2cab7ae) will increase coverage by 0.0%.
The diff coverage is 80.6%.

❗ Current head 0638764 differs from pull request most recent head 0b58b5f. Consider uploading reports for the commit 0b58b5f to get more accurate results

Impacted Files	Coverage Δ
contracts/account/proxy/src/contract.rs	99.1% <ø> (ø)
contracts/native/account-factory/src/error.rs	100.0% <ø> (ø)
contracts/native/account-factory/src/lib.rs	100.0% <ø> (ø)
contracts/native/ibc-client/src/ibc.rs	15.1% <0.0%> (-0.3%)	⬇️
contracts/native/ibc-client/src/queries.rs	25.0% <0.0%> (ø)
contracts/native/version-control/src/error.rs	25.0% <ø> (ø)
packages/abstract-core/src/core/manager.rs	34.2% <ø> (ø)
packages/abstract-core/src/core/proxy.rs	61.1% <ø> (ø)
packages/abstract-core/src/ibc_host.rs	3.5% <ø> (ø)
...ckages/abstract-core/src/native/account_factory.rs	61.5% <0.0%> (-18.5%)	⬇️
... and 27 more

[Kayanski]

The logic is the following :

0. The admin registers the port they want to connect on from the remote chain
1. On channel connect, we save the associated port in storage (channel_id -> port_id)
2. On who_am_i verification, we check that the chain -> port_id corresponds to the relation that was registered in storage (through chain_id --> channel_id --> port_id that we now have).

Potential attack vectors :

0. No-one can connect to the contract from IBC if the chain is not registered (good to prevent future integrations)
1. If a chain_id --> port_id pair is registered, someone can fake both and connect to the contract. This can't be prevented with this approach. If that happens, the admin can still remove the saved channel and overwrite the chain_id --> port_id association