[SPEC] Implement timed execution strategies

[drewstone]

Overview

Currently when the relayers hear of signed proposals from the external signing system they proceed to submit the respective transactions. This is something ALL of the relayers may likely attempt to do. While we have no coordination on submitting this tx, we should implement a system for designing strategies around submission that can behave differently in different settings.

One particular setting is whether we want to immediately send txes or not for a given chain. Ethereum is an expensive place to make txes, therefore it might be wise to consider updating the Ethereum SignatureBridge only once every few hours (or let another relayer pay the tx cost). If there are many deposits on all other sides of the bridge, we may not want to execute this update as an operator of the relayer. If there exists a signed proposal for an anchor update and a user is intent on bridging to Ethereum, they can eat the cost themselves by submitting it themselves (this should also be an eventual option in the dApp).

Spec details

We should spec out what this might look like and then implement it. This would likely amount to putting in some constraints to the transaction submission and the respective (chain, proposal type) combination at hand. For example (Ethereum, AnchorUpdate) might behave differently than (Polygon, AnchorUpdate), etc.

We can consider optimising this around the fixed USD cost of txes. For example by targetting an amortized $/hour cost for the relayer. The spec writer/implementer should take this into account and also present a design that is flexible and general enough to support different behaviours.

[shekohex]

This now is going to be addressed partially in the #359