Update multiple crates to ensure bitvec 0.22.3 is being used

[conradoplg]

Motivation

librustzcash was updated to use bitvec 0.22 and due to a package conflict with funty, we need to update all crates that use bitvec in order to use the recent librustzcash (in particular its zcash_primitives crate which will be used by the ZIP-244 PRs).

This will also solve issues with the updated zcash_script.

Solution

Update all crates that use bitvec to versions that use bitvec 0.22.

This required fixing some of Zebra code that directly uses bitvec since its API changed since 0.17 which was being used before. I added a lot of expects because bitvec now can return an error when instantiating from slices; but per its documentation that can only happen if the slice is too big, and all of our usages are with fixed-size small slices.

Note: I've included the zcash_primitives reference in Cargo.toml but it's not being actively used right now, but it will be used soon with the ZIP-244 PRs; I wanted to make sure everything works with it.

The jubjub upgrade also resolves #1798

Review

This blocks the ZIP-244 PRs (#2129 and #2165).
(Spoiler: I've tested this code with #2129 and it works 🎉 )

@jvff might want to review since he had to make pretty much the same changes while updating zcash_script
@dconnolly might want to review the bitvec usage changes to make sure I haven't accidentally changed the behavior

Reviewer Checklist

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

Follow Up Work

Update redjubjub when it's released: #2352
Update librustzcash when it's released: #2353

[dconnolly]

This is great!

I want to find a way to document that as of these versions of jubjub and redjubjub, the ZIP-216 consensus rules are being checked. We could annotate this at each location in the source, but I don't know if that's best. Maybe @teor2345 has opinions

[jvff]

The changes are looking good! I added some suggestions, but they're on the edge of being out of the PR's scope, so feel free to ignore them or leave them for later.

There's only one thing that is worth taking a closer look: accessing 10 bits from a BitSlice that seems to only have 8 bits. To be fair, this is likely also out of the PR's scope, but since it might be an existing bug, it might be a good idea for someone else to double check.

[teor2345]

I want to find a way to document that as of these versions of jubjub and redjubjub, the ZIP-216 consensus rules are being checked. We could annotate this at each location in the source, but I don't know if that's best. Maybe @teor2345 has opinions

This is a hard one, since there's no obvious place to put it.

Can we just quote the relevant parts of ZIP-216 in the transaction verifier module doc comment?

[teor2345]

I'm ok with this PR, but I'd like @dconnolly to check the out-of-range bit read fix.

[dconnolly]

I want to find a way to document that as of these versions of jubjub and redjubjub, the ZIP-216 consensus rules are being checked. We could annotate this at each location in the source, but I don't know if that's best. Maybe @teor2345 has opinions

This is a hard one, since there's no obvious place to put it.

Can we just quote the relevant parts of ZIP-216 in the transaction verifier module doc comment?

Done in ab14a0a

[teor2345]

I think everything got resolved and fixed.

I'm keen to merge this soon to avoid conflicts.

All concerns have been addressed and bugs have been fixed.

[dconnolly]

👍