Adjust robustness of MTX broadcaster

[area]

While investigating issues that users were having with the metatransaction broadcaster, this is where we've arrived, fixing two issues:

• An error that would result in trying to hexlify a transaction response object, rather than a signed transaction. This was due to a confusion between signer.sendTransaction and provider.sendTransaction in the rebroadcasting logic.
• Some sensitivity to accidentally re-using nonces. We weren't really using the NonceManager functionality, so I've reworked the ExtendedNonceManager a fair bit to use it, and it's now much closer to the default NonceManager but with rebroadcasting logic.

Reproducing issues around this determinsitically is hard; I've done my best with some tests, but I couldn't get the exact errors we saw in production. These changes are currently live on QA, and will hit production before the next release (or maybe even before this is merged), so it's going to be an ongoing battle, but let's still review / improve these changes as normal!

[kronosapiens]

Is this meant to be part of the final implementation?

[area]

Yeah, I guess this can be removed now that we have the try/catch.

[area]

A demoralising update.

From the frontend side, we need to guarantee, as strongly as possible, that the hash returned is the hash of the transaction that does the metatransaction. The previous implementation, rebroadcasting the transaction if it did not succeed, does not guarantee that (as if we have to change the nonce, the hash will change).

I've ended up at this much simpler implementation that refreshes the nonce every request (as a typical signer would), but retrying if an error relating to the nonce is seen when doing so, and only returning the transaction hash when that doesn't happen (which will be when the transaction is mined).

For cases where the broadcaster ends up behind, it'll catch-up, and for cases where the broadcaster ends up ahead it'll reset itself. The latter can't be tested properly locally currently, as hardhat returns an error if you use a too-big nonce, which is not typical (usually, such a transaction would sit in the mempool of a node until dropped or all the in-between nonces are filled in). That would all work with a typical signer - the custom retry functionality deals with situations where multiple requests are made simultaneously and we end up with nonce collisions.

The (previous) 'clever' version might be appropriate to use with the wormhole relayer - where we don't care about the transaction hash of something happening, we just care about it happening, but it can use this provider for now, as well, as far as I'm concerned.

[kronosapiens]

Looks good to me