Split storage errors by match type: TXID or WTXID

[teor2345]

Motivation

ZIP-401 requires mempools to match some transaction rejections by transaction::Hash, rather than UnminedTxId.

Zebra already implements some rejections that should be matched by transaction::Hash. So we can modify our existing matches, and prepare for ZIP-401.

Closes #2819.

Specifications

https://zips.z.cash/zip-0401

Each node also MUST hold a FIFO queue RecentlyEvicted of pairs (txid, time), where the time indicates when the transaction with the given txid was evicted. The txid (rather than the wtxid ...) is used even for version 5 transactions after activation of NU5.

Designs

For rejected invalid transactions (i.e. transactions that failed verification or storage), Zebra should match:

• transactions with failed effecting data (SpendConflict, Expired): check for the same TXID (mined_id()) - this ticket
• other rejection reasons: check for the same WTXID (UnminedTxId) - Add transactions that failed verification to the mempool rejected list #2818

Solution

• match SpendConflict, Expired, and RandomlyEvicted by transaction::Hash
• match FailedVerification by UnminedTxId

Review

I'd like an initial review from @conradoplg and @upbqdn, because they're implementing the related ZIP-401 tickets.

Does this design work for you?
Is this a minimal change?

Reviewer Checklist

• Code implements Specs and Designs
• Tests for Expected Behaviour
• Tests for Errors

Follow Up Work

We might want to split FailedVerification into effects failures and authorization failures, see #2834.
But this change is not required for a minimal mempool implementation.

[conradoplg]

I like it!

For #2821 I think we'll need to split this even more:

• rejected_exact (invalid) (cleared on grow)
• rejected_same_effects:
  • expired (cleared on reset)
  • spend_conflict (cleared on grow)
  • excess (cleared on ZIP-401 timeout)

Should we do this in this PR, or in a following one?

[teor2345]

For #2821 I think we'll need to split this even more:

* `rejected_exact` (`invalid`) (cleared on `grow`)

* `rejected_same_effects`:
  
  * `expired` (cleared on `reset`)
  * `spend_conflict` (cleared on `grow`)
  * `excess` (cleared on ZIP-401 timeout)

Should we do this in this PR, or in a following one?

I was planning on doing some of that split in #2694, and then whatever is left over we can do in #2821.

[conradoplg]

Looks good!