Sapling Nullifier

[dconnolly]

https://zips.z.cash/protocol/protocol.pdf#nullifierset

[yaahc]

Working on this next.

And to answer a question from the primary refinement issue:

One of these is a nullifier for Sprout, while the other is for Sapling – should these be the same type or different types?

I doubt this is comprehensive but from what I can tell there are two issues at play here.

1. we don't want to duplicate logic that is shared between both types
2. we don't want to accidentally mix up Sapling and Sprout nullifier sets.

To me the latter seems like the bigger concern. Also, I have some ideas for how we could deduplicate the underlying implementation logic while still having distinct types for type checking purposes ranging from attaching all the logic to traits to just using newtypes to differentiate between the different nullifier sets. Either way I'd like to start with two distinct types here and move to a shared one if needed based on gathered experience.

[yaahc]

@ZcashFoundation/zebra-team should I place the nullifier types in transaction or should I create a nullifier module similar to how we have address, notes, and keys modules for sapling/sprout types.

I'm leaning towards new module

[hdevalence]

New module sounds good to me. It's always easier to re-export from submodules than to cut one big module into smaller ones.