Un-reject transactions which depend on newly created outputs

[teor2345]

Motivation

Zebra rejects transactions that spend outputs that haven't been mined yet.

But when those outputs are mined, we continue to reject those transactions until:

• the next reset (average ~300 blocks or ~6 hours), or
• the rejection expires (60 minutes in ZIP-401, see Limit the size and age of the ZIP-401 rejected transaction ID list #2759)

Design

• Expire FailedVerification and SpendConflict rejections every time we get a new block.
• Limit the size of the FailedVerification and SpendConflict list to 40,000 entries

This size limit is the same as ZIP-401, but the lists should be separate.

This might mean that we need to split the error types and the lists again.

Alternative Designs

This alternative design depends on the OutPoints and nullifiers from ticket #2631.

We could keep lists of:

• missing inputs in each Invalid rejection, and remove the rejection when all the inputs are mined
• conflicting inputs in each SpendConflict rejection, and remove the rejection if all its conflicting inputs are rejected

Follow Up

Split transaction::Verifier errors the same way, see #2834.

[mpguerra]

Hey team! Please add your planning poker estimate with ZenHub @conradoplg @dconnolly @jvff @oxarbitrage @teor2345 @upbqdn

[conradoplg]

My arguments for the quick fix:

When a transactions fails due to missing inputs, I think they just timeout. We'd need to detect that and include somehow the missing inputs in the error being returned, which seems tricky. Otherwise we can just query the state to get the missing inputs, but it also seems awkward... Also, in a sense, it seems this would basically recreate the timeout for missing inputs but elsewhere.

Handling SpendConflict seems easier, but I have questions about efficiency. I'll start implementing the quick fix while I think more about this...

[teor2345]

I'm probably going to run out of work tomorrow, and there are no unblocked tasks left in the sprint, so I'm moving this one back in.