pm: Do not submit a new tx for a winning ticket if another tx is already pending

[yondonfu]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Currently, if gas prices are rising, then its possible for a tx to be submitted for a ticket at the head of the queue. But, that tx will sit pending for awhile and internally the node will get a context timeout from waiting for the tx to confirm. Then, the node will try to submit the ticket again because it has not been removed from the head of the queue. This second tx will confirm after the first pending tx confirms and will revert because the ticket will already be used on-chain by the first tx.

Describe the solution you'd like
A clear and concise description of what you want to happen.

The most basic thing to ensure first is that there are never multiple in-flight txs for a single tx.

An improvement might be to track in-flight txs for tickets and then replace them with a higher gas price similar to what is done for reward transactions.

[kyriediculous]

We could add a pending bool field to the database and add this to the selection query. When we mark a winning ticket as redeemed we can set it back to false.

An improvement might be to track in-flight txs for tickets and then replace them with a higher gas price similar to what is done for reward transactions.

The replacement behaviour for reward calls was removed awaiting the introduction of the maxGasPrice feature.

Now that this feature has landed in the latest release perhaps we can consider re-introducing this feature.

[yondonfu]

Fixed by #1923