Support Aliasing with Relayer API

[AdityaSripal]

Aliasing is currently unsupported with the relayer because the RelayByTx endpoint batches the UpdateClient and packet messages together.

When it does this, it tries to find the client using the client_id emitted in the events of the packet handler. However, since we are emitting the channel id here in the aliasing case, the client is not found and RelayByTx returns an error.

There are a number of possible solutions to this:

1. Create new event key/values in the packet handler to emit the underlying clientID if it is an aliased channel. The relayer can then update this client using this ID and use the packet level fields only for packet reconstruction. This is probably the best approach as it is clean and can be re-used for something like conditional clients should that become necessary.
2. Have the relayer handle aliasing internally, it can check the alias key first before trying to retrieve the client. This is also easy, requires no changes to ibc-go but embeds aliasing logic into relayer as an exceptional case to handle.
3. Allow RelayByTx to create the packet processing message without updateClient. Here the caller of the API is responsible for orchestrating the Update and Packet messages separately for the aliasing case. This is not recommended as it would be complex to support aliasing for users of the relayer API

[linear]

IBCSOL-238 Support Aliasing with Relayer API