feat(L2toL2CrossDomainMessenger): update `sendMessage` to return relay message hash

[tremarkley]

Description

Update the L2toL2CrossDomainMessenger.sendMessage function to return the message hash of the relayed message.

Reasoning

This change allows contracts built on top of the L2toL2CrossDomainMessenger to construct composable messages that depend on the success of other messages that have been relayed by the L2toL2CrossDomainMessenger without having to construct the message hash on their own.

Example

Let's say I build a contract on top of SuperchainWETH, that has two functions sendETH and unwrapAndCall. sendETH handles wrapping the ETH to WETH and sending the WETH to the destination chain. unwrapAndCall handles unwrapping the WETH to ETH and then sending it to the recipient. In order for this to work properly, the withdraw and SafeCall.Call cannot be done until it has been confirmed that WETH has successfully been relayed to the destination chain. With the current implementation of L2toL2CrossDomainMessenger this requires manually constructing the message hash for the relayERC20 call: https://gist.github.com/tremarkley/644f8c542dd2224b31bcbbacbb73c365#file-superchainethwrapper-sol-L72. If L2toL2CrossDomainMessenger.sendMessage and SuperchainWETH.sendETH were updated to return the message hash, then this is simplified to: https://gist.github.com/tremarkley/ecba1fe4ece9c7fa6fa7b2d6fac5ae25#file-improvedsuperchainethwrapper-sol-L72

[tynes]

An interesting side effect of your implementation is that because it is 2 cross chain messages, there is no guarantee that they MUST be played in the correct order, it is possible to consume the messages out of order. You could imagine purposefully consuming the messages out of order as a grief. Would this be problematic for the smart contract that you are building? Is there a simple recovery path if the messages are consumed out of order? The answers to these questions will help to guide the low level abstractions, to ensure that they provide enough power to express useful and safe actions

[tremarkley]

@tynes

Would this be problematic for the smart contract that you are building? Is there a simple recovery path if the messages are consumed out of order?

If the messages were consumed out of order and the unwrapAndCall message was executed before relayERC20, then the call to unwrapAndCall would revert: https://gist.github.com/tremarkley/ecba1fe4ece9c7fa6fa7b2d6fac5ae25#file-improvedsuperchainethwrapper-sol-L53. Therefore, the unwrapAndCall message could continue to be executed until it succeeds: https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/L2ToL2CrossDomainMessenger.sol#L161