Detect when a transaction has not been propagated to the mem pool.

[fleupold]

For GPv2 we today tried to submit a solution, which apparently was sent to a "bad node" and not propagated to the mem-pool.

The retry logic kept waiting for confirmation until the timeout was reached. However, it would be nice if it could detect that the tx is not part of the mempool. @denisgranha suggested two approaches:

1. Use eth_getTransactionCount in the pending block and see if it matches your count of txs.
2. Use eth_getTransactionByHash in the pending block and see that it returns something

I'm not sure if this logic should live here or rather in ethcontract-rs, but likely not in GPv2 (as it seems generic enough to be useful to other projects).

Here are the logs showing the timeout and here is the tx that was successfully mined just after the timeout:

https://etherscan.io/tx/0xbb06ba8efc94911562387cf40a376bb9339c203a2b1015683034c3cffc0d3a4d

[fleupold]

This happened again: https://gnosisinc.slack.com/archives/CQZBU9T5J/p1617729257000700

[vkgnosis]

I am not sure if the pending block works this way. Googling around I find some sources saying that it is only relevant if the node is mining. https://ethereum.stackexchange.com/questions/11298/web3-eth-getblockpending-returns-latest-block-not-pending-block-is-that-ex openethereum/parity-ethereum#5014 . Either way the documentation doesn't specify what pending block means.
We should be able to detect if the node doesn't know about a transaction with eth_gettransactoinbyhash call. If we see this isn't the case we can resubmit. Or we can always resubmit in intervals and detect and ignore "gas price hasn't increased enough" errors. We'll need that anyway because a resubmit could go to a different load balanced node which does know about the transaction.

[fleupold]

I have empirically used pending block and was able to see transactions that are shown as pending on etherscan but not yet mined. We can maybe ask the OE team what it specifically means in their context.