Custom message handler and decoders

[iFrostizz]

TBD

Why this should be merged

How this works

Add a new chainlink config parser with the keys:

• aggregators-to-replicas: Expects a key-value format in the form of

{
    "0xaddress1...": "0xaddress2...",
    "...": "..."
}

0xaddress1... here would be the address of a Chainlink price feed that emits AnswerUpdated and 0xaddress2... the contract that is supposed to support the importEvent function on the destination blockchain.

• max-filter-addresses: Since potentially a lot of aggregators have to be filtered, this variable can be used to bound the maximum of addresses filtered in one iteration and will offload it to the next one. For instance, if you set max-filter-addresses: 10, you will never pass more than 10 addresses in one eth_filterLogs call.
• destination-blockchain-id: Self explanatory

Add a new MessageDecoder interface

Every message handler should be made of a message decoder (which conforms to the MessageDecoder interface) as well as the existing MessageHandler.
The MessageDecoder has the function Decode which takes in the block header and the ethclient and returns an array of WarpMessageInfo. It should be enough for most applications since even the logs are up to the implementer to fetch, they don't even have to use eth_filterLogs.

ChainlinkMessageHandler that implements MessageHandler

This was quite trivial given that the generation of the proof was already written at https://github.com/ava-labs/event-importer-poc/blob/7993818e0acabbc71d693fa66064235c750f144f/proofs/proof_utils.go. The rest is handed out by the decoder and parsed as a ChainlinkMessage.

How this was tested

TBD

How is this documented

See "Extending the relayer" at https://docs.google.com/document/d/12MuoEeECCWr3jNgYAZJrSCXv3tkYoFKO_DLHPCLU2EE/edit?usp=sharing

[iFrostizz]

This looks a bit brittle but how can we do a gas estimation given a subnetevm client ?