deps(librustzcash): Upgrade zcash dependencies for NU6

[oxarbitrage]

Motivation

We want to use the current main version of librustzcash so we can remove unstable features.

We will get back to depend on a release after librustzcash components are released.

Close #8713

Solution

Upgrade, fix problems.

Draft until CI pass as there might be issues for example in the deny.toml.

Tests

No tests were added as our current suite should be enough coverage.

Follow-up Work

PR Author's Checklist

• The PR name will make sense to users.
• The PR provides a CHANGELOG summary.
• The solution is tested.
• The documentation is up to date.
• The PR has a priority label.

PR Reviewer's Checklist

• The PR Author's checklist is complete.
• The PR resolves the issue.

[oxarbitrage]

The "Release crates / Check crate release dry run (pull_request)" check will not pass for this PR because we are relying on a GitHub repository for librustzcash instead of a version from crates.io. This is not allowed in our release process.

If this PR gets approved, we will need to perform an admin merge. As a side effect, all future pull requests will also require admin merges until we can revert to a proper release. An alternative is to make the "Release crates / Check crate release dry run (pull_request)" check not required. The test will fail, but we will still be able to merge. This should be a temporary measure, but it seems better than having to admin merge every subsequent pull request.

[mpguerra]

An alternative is to make the "Release crates / Check crate release dry run (pull_request)" check not required. The test will fail, but we will still be able to merge. This should be a temporary measure, but it seems better than having to admin merge every subsequent pull request.

Let's go ahead and do this then. Does anyone know how/where to do this?

[conradoplg]

I think it's preferrable to point to a commit in the main branch, and not the main branch itself, e.g.

{ git = "https://github.com/zcash/librustzcash/", rev = "5a4a3e06dcd2cf5bdf79a7cd48709b58693c65f0" }

This will make it less likely to suddenly break if something incompatible ends up being merged into their main.

[oxarbitrage]

I think it's preferrable to point to a commit in the main branch, and not the main branch itself, e.g.
...

I think we can do that for sure but by the talks we had with the ECC engineers in multiple meetings we decided to use the last main as all that it is and will be there is part of the next release, reducing the delta.

This will make it less likely to suddenly break if something incompatible ends up being merged into their main.

My understanding is that we actually want to break if something like that happens.

I don't mind changing this up to a commit but just wanted to point that out.

[conradoplg]

I think it's preferrable to point to a commit in the main branch, and not the main branch itself, e.g.
...

I think we can do that for sure but by the talks we had with the ECC engineers in multiple meetings we decided to use the last main as all that it is and will be there is part of the next release, reducing the delta.

This will make it less likely to suddenly break if something incompatible ends up being merged into their main.

My understanding is that we actually want to break if something like that happens.

I don't mind changing this up to a commit but just wanted to point that out.

I realized this is all moot since Cargo.lock already ensures the same commit will be used even if main is updated, so we're good. (I'm so used to working on a library that I forget about this 😆 )

[oxarbitrage]

I realized this is all moot since Cargo.lock already ensures the same commit will be used even if main is updated, so we're good. (I'm so used to working on a library that I forget about this 😆 )

That's good to know, thanks for pointing it out.

[oxarbitrage]

@Mergifyio refresh

[mergify]

refresh

✅ Pull request refreshed