Reject duplicate Sapling and Orchard nullifiers

[teor2345]

Motivation

Zebra needs to reject duplicate sapling and orchard nullifiers, to prevent double-spends.

See #2231 for details.
This PR finishes the shielded part of #2231, but does not close that ticket.

Solution

This code is almost identical to the sprout code in the previous PR:

• Add sapling and orchard duplicate nullifier errors
• Reject duplicate finalized sapling and orchard nullifiers
• Reject duplicate non-finalized sapling and orchard nullifiers

These tests are based on the previous PR, with sapling and orchard-specific changes:

• Refactor sprout nullifier tests to remove common code
• Add sapling nullifier tests
• Add orchard nullifier tests

The specific test changes are:

• sapling and orchard only have one nullifier per Spend/Action, so there is no need for "same Spend/Action" tests
• we can't reliably make orchard nullifiers distinct, because they must be valid Pallas points, so we just skip the test case if they are the same
• various minor structural and validation changes

Review

@jvff can review this PR - it's not urgent at all.
This code is unlikely to conflict with any other code.

Reviewer Checklist

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

Follow Up Work

Prevent transparent double-spends #2231

[jvff]

Everything looks good. There are only a few questions I'm a bit unsure of. Two are in the code, and another follows below. I also ended up adding too many optional suggestions. Feel free to ignore them, I don't know why but for some reason I'm feeling more creative than normal. I apologize for any noise this creates 😅

I'm not sure this is a valid question, but would it make sense to add another test that adds two different nullifiers? The current acceptance tests only add one nullifier 🤔

This could go further and mirror all of the rejection tests but with different nullifiers to check if they are accepted. That's a lot of tests, so if this is something that's useful, it could be done in a separate PR.

[teor2345]

I'm not sure this is a valid question, but would it make sense to add another test that adds two different nullifiers? The current acceptance tests only add one nullifier 🤔

This could go further and mirror all of the rejection tests but with different nullifiers to check if they are accepted. That's a lot of tests, so if this is something that's useful, it could be done in a separate PR.

The integration tests already add thousands of nullifiers. So I'm not sure if adding two nullifiers in the unit tests gives us significantly better test coverage.

(There are already ~15 tests across the 3 shielded pools.)