Added optional memo to ics20 packets

[nicolaslara]

IBC has introduced an optional memo field on the ICS20 transfer packet. The memo enables features such as Osmosis cross chain swaps, and forwarding tokens using the packet forward middleware.

The change in this PR allows users to specify the memo to use when transferring CW20s. Note that since the memo is optional (both in the messages passed to the contract and the serialization of the Ics20Packet) this change will only affect the case when the memo is included in TransferMsg by the user. In short, this change should be backwards compatible.

[CLAassistant]

All committers have signed the CLA.

[nicolaslara]

Tested this on mainnet as follows:

• Stored the compiled version of this contract
• Instantiated it
• Created a channel between that contract and osmosis: osmosis/transfer:channel-762 <> juno/wasm.juno1nnm4adhg6yz7a0s8ys0zwmm92reh66swqpfyp30m7dv3lawqtyuqh2utcu:channel-230
• Setup relayer for those channels

• Sent some Neta from the Neta contract on Juno to Osmosis with a memo:

  • Send tx
  • Receive tx (note the ICS20 memo "this is a test")
  • Tried sending back to juno with a memo, which failed as expected since the receive side doesn't support the memo:
  • Send tx
  • Properly sent it back without the memo:
  • Send tx
  • Receive tx

  (If you notice the long time time between txs it's because it took me a while to discover allow lists on cw20_ics20 and copy pasting a CLI command made it so I kept sending to an osmosis addr instead of juno 😅)

[nicolaslara]

Signed!

[webmaster128]

Okay, so this breaks existing Rust code when constructing or destructing Ics20Packet or TransferMsg. Those are public symbols. However, I am not sure if this contract is embedded as a library somewhere.

[nicolaslara]

Okay, so this breaks existing Rust code when constructing or destructing Ics20Packet or TransferMsg. Those are public symbols. However, I am not sure if this contract is embedded as a library somewhere.

Right. I don't think this merits having two different v1 and v2 structs, but happy to have this be tagged in a 2.x major version (like you said, I don't think this is used as a library)

Having serialization be backwards compatible should be enough to be able to update the live contracts

[webmaster128]

To be on the safe side, let's create a 1.x release branch befor this merge. Then we can have breaking changes on main that people can use. There will be a 2.0 release series of the contracts in summer anyways.