Add Protocol Address to RelayerID

[cam-schultz]

Context and scope
ApplicationRelayers are associated with exactly one RelayerID, which is the Keccak256 hash of the tuple (sourceBlockchainID, destinationBlockchainID, sourceAddress, destinationAddress). This key is used to store the checkpointed height that each ApplicationRelayer has processed.

This issue is to investigate adding protocolAddress to the RelayerID tuple. This has both logical and architectural advantages. Logically, an ApplicationRelayer is intended to represent a distinct cross-chain message route. They do not, however, consider the message protocol, meaning that a distinct address on a specific blockchain sending messages over two protocols is not distinguished by the ApplicationRelayer. There are edge cases in which messages may be missed if the relayer application's configuration adds and removes message protocols. Associating the protocol address with the checkpointed block height would address these.

On the architectural side, distinct message protocol handling is implemented by MessageHandler and MessageHandlerFactory. MessageHandlers are created external to the ApplicationRelayer and passed in as arguments to ProceeHeight. This requires a two-pass approach, as well as a MessageCoordinator to perform the correct mapping. With the proposed change, MessageHandlerFactory could instead be encapsulated in ApplicationRelayer, simplifying the processing logic for ApplicationRelayer callers, and simplifying the ProcessHeight interface.

Discussion and alternatives

• Add protocolAddress to the RelayerID tuple

Open questions
What are the migration steps for existing awm-relayer instances with databases keyed without the protocolAddress?