Provide Zebra compatibility: re-enable and fix zcash_client_backend, update prost dependency version

[dmidem]

Updates the repository to ensure compatibility with the zebra project.

Changes:

1. Uncommented the zcash_client_backend crate in the root Cargo.toml. Initially it was commented out under the assumption that it wasn't utilized by Zebra. However, it has been identified that Zebra relies on this crate.

2. Synchronized zcash_client_backend crate with zcash_note_encryption updates.

3. Updated the prost dependency version in the root Cargo.toml (the pinned version 0.12.3 caused compatibility issues with Zebra’s dependencies, preventing compilation).

[PaulLaux]

Let's add a comment above line 9
# zcash_client_backend and zcash_client_sqlite are not compatible with OrchardZSA

[PaulLaux]

maybe this is the source of CI fail?

[dmidem]

It turns out that's not the case (or not the only case). I created a new branch from zsa1 and made only this single prost version change there. I committed it and created a new PR - the cargo vet CI check passed without any issues. This can even be verified without a PR: after I made that change in the repository, I ran cargo check, then git diff Cargo.lock: the Cargo.lock file wasn't changed.

However, when I uncommented zcash_client_backend in Cargo.toml and then ran cargo check, git diff Cargo.lock, it started to show a lot of differences like:

+[[package]]
+name = "anyhow"
+version = "1.0.89"
+source = "registry+https://github.com/rust-lang/crates.io-index"
+checksum = "86fdf8605db99b54d3cd748a44c6d04df638eb5dafb219b135d0149bd0db01f6"
...

This means that adding zcash_client_backend causes the cargo vet issues in CI that we observed.

I guess this happens because zcash_client_backend uses additional dependencies in its Cargo.toml that require newer versions of sub-dependencies like anyhow, which are not marked as audited for cargo vet in our git branch (the audited list is contained in the supply-chain folder of the repository).

I think the reason for this is that the maintainers of the original librustzcash repo maintain consistency between the Cargo.toml files of the crates, the Cargo.toml/Cargo.lock in the root, and the audited list in the supply-chain folder. But in our fork, we have copies of zcash_client_backend/Cargo.toml and the supply-chain folder from different versions of the original branches. I'm not sure though - we need to check the history of our commits to find the source of the difference.

Additionally, I tried a simple copying the supply-chain folder from the upstream version (https://github.com/zcash/librustzcash/tree/main/supply-chain), but it didn't resolve the issue. Maybe I missed something - I'm continuing to work on it.

[dmidem]

I managed to solve the cargo vet issue. Here's what I did:

1. Ran git log zcash_client_backend/Cargo.toml and found the latest commit message for it:

Zsa1 is updated to a more current upstream version, commit:
c3eace4982dfea82f89758f40c1db2e82a138e98

2. Switched to commit c3eace4982dfea82f89758f40c1db2e82a138e98 (which corresponds to zcash/librustzcash#1383 in the original repo), took the Cargo.lock file from that commit and placed it into the zebra-compat-enable-backend branch.

3. Ran cargo check, cargo test, cargo build, and also cargo vet --locked locally in zebra-compat-enable-backend branch to ensure everything works.

4. Committed the changes — now all CI checks have passed.

Summary:

I managed to use the existing set of audited dependencies here, but had to use an older version of Cargo.lock (updated by cargo check to include our QED-it-specific dependency crates like orchard, etc.)

[alexeykoren]

It is also commented in CI workflows. Specifically - workflows/ci.yml:L196-198

Shall we ucomment there too?

[dmidem]

That makes sense, thanks @alexeykoren, I just fixed it and commited the change.

[alexeykoren]

LGTM (except CI failure of course)