build(deps): Upgrade ECC crates for Zebra v2.0.0-rc.0 release candidate

[oxarbitrage]

Motivation

We need to upgrade the ECC dependencies for the next release.

This PR will also close #8809

Solution

• Upgrade the dependencies to match zcashd 6.0.0 release candidate - https://github.com/zcash/zcash/blob/v6.0.0-rc1/Cargo.toml
• Additional patches are also needed: https://github.com/zcash/librustzcash/blob/1410f1449100a417bfbc4f6c7167aa9808e38792/Cargo.toml#L165-L170
• Upgrade secp256k1 now that we can and do some deny.toml cleanup.

Tests

All CI tests should pass.

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.

[str4d]

Note that by upgrading to those dependencies without setting the mainnet activation height, you are creating a mixed-consensus node state. I don't know how you manage that in Zebra; in zcashd we upgraded to these in the 6.0.0 release PR itself (not the RC), in the same commit as the mainnet activation height. To split up the upgrade, we upgraded first (using a [patch.crates-io] directive) to the librustzcash commit right before setting the mainnet activation height.

[oxarbitrage]

Ok, thanks for the head-up @str4d !

However, when i tried to do it as that, it seems to be an inconsistency problem with the revisions for zcash_client_backend that zcashd does not has to build. Can you take a look?

• Versions: https://github.com/ZcashFoundation/zebra/pull/8918/files#diff-2e9d962a08321605940b5a657135052fbcef87b5e360662bb527c96d9a615542
  -Error building zcash_client_backend using those versions: https://github.com/ZcashFoundation/zebra/actions/runs/11255087378/job/31293900346?pr=8918#step:12:248

[oxarbitrage]

@Pili FYI: We decided with @str4d and other ECC folks in a meeting today that we want to do the Zebra v2.0.0-rc.0 with the patches pointing to commits just before the mainnet activation heights, this is the same zcashd did and should be the less risky process to follow.

To go over #8918 (comment) other patches were also needed. I am updating the PR with all that but i think we are back in track again.

[arya2]

Looks good, I left a couple suggestions for cleanup and it looks like the entry for elasticsearch in the deny.toml is outdated, but there are no blockers.

[oxarbitrage]

I tried to remove elastic in 6c21ecb but had to revert in a568cb8