Re-land zcash keyring support

[cypt4]

Resolves brave/brave-browser#32303

Submitter Checklist:

• I confirm that no security/privacy review is needed and no other type of reviews are needed, or that I have requested them
• There is a ticket for my issue
• Used Github auto-closing keywords in the PR description above
• Wrote a good PR/commit description
• Squashed any review feedback or "fixup" commits before merge, so that history is a record of what happened in the repo, not your PR
• Added appropriate labels (QA/Yes or QA/No; release-notes/include or release-notes/exclude; OS/...) to the associated issue
• Checked the PR locally:
  • npm run test -- brave_browser_tests, npm run test -- brave_unit_tests wiki
  • npm run presubmit wiki, npm run gn_check, npm run tslint
• Ran git rebase master (if needed)

Reviewer Checklist:

• A security review is not needed, or a link to one is included in the PR description
• New files have MPL-2.0 license header
• Adequate test coverage exists to prevent regressions
• Major classes, functions and non-trivial code blocks are well-commented
• Changes in component dependencies are properly reflected in gn
• Code follows the style guide
• Test plan is specified in PR before merging

After-merge Checklist:

• The associated issue milestone is set to the smallest version that the
  changes has landed on
• All relevant documentation has been updated, for instance:
  • https://github.com/brave/brave-browser/wiki/Deviations-from-Chromium-(features-we-disable-or-remove)
  • https://github.com/brave/brave-browser/wiki/Proxy-redirected-URLs
  • https://github.com/brave/brave-browser/wiki/Fingerprinting-Protections
  • https://github.com/brave/brave-browser/wiki/Brave%E2%80%99s-Use-of-Referral-Codes
  • https://github.com/brave/brave-browser/wiki/Web-Compatibility-Exceptions-in-Brave
  • https://github.com/brave/brave-browser/wiki/QA-Guide
  • https://github.com/brave/brave-browser/wiki/P3A

Test Plan:

[cypt4]

/build ios

[github-actions]

[puLL-Merge] - brave/brave-core@23383

Here is my review of the pull request:

Description

This PR adds support for Orchard key generation and address derivation in the Brave Wallet. The main motivation seems to be expanding Brave Wallet's ZCash capabilities to enable shielded transactions through the Orchard protocol.

Changes

Changes

• components/brave_wallet/browser/BUILD.gn, components/brave_wallet/browser/internal/BUILD.gn
  • Added new dependencies and source files related to Orchard key generation
• components/brave_wallet/browser/internal/hd_key_zip32.cc, components/brave_wallet/browser/internal/hd_key_zip32.h, components/brave_wallet/browser/internal/hd_key_zip32_unittest.cc
  • Implemented Orchard key generation logic following ZIP-32 specification
• components/brave_wallet/browser/zcash/rust/*
  • Added Rust implementation of Orchard extended spending key derivation
• components/brave_wallet/browser/zcash/zcash_keyring.cc, components/brave_wallet/browser/zcash/zcash_keyring.h
  • Updated to derive and store Orchard keys
  • Added new methods to get shielded addresses and raw Orchard address bytes
• components/brave_wallet/common/*
  • Defined feature flag for enabling Orchard
  • Updated common utilities to check Orchard feature flag
• components/brave_wallet/common/zcash_utils.cc, components/brave_wallet/common/zcash_utils.h
  • Added utilities for parsing and constructing unified addresses with Orchard
• Unit tests
  • Added tests for Orchard key derivation and unified address handling

Security Hotspots

1. Orchard key generation and derivation
   • Ensure the cryptographic operations are implemented securely without any bugs or weaknesses. The Rust implementation should be carefully audited.
2. Parsing and construction of unified addresses with Orchard
   • Vulnerabilities in the parsing logic could potentially allow creation of malformed addresses. The parsing and serialization code should be properly tested.
3. Feature flag for enabling Orchard
   • Access to the Orchard functionality is gated by a feature flag. Verify the flag is set securely and can't be bypassed.

Overall, this is a significant change that introduces a complex new ZCash protocol to the wallet. The implementation should undergo thorough security testing and auditing, especially the core cryptographic components. Users' privacy and funds security depends on the robustness of the Orchard integration.

[bridiver]

This is a re-land disabled by default and @brave/crypto-wallets-core already approved the original PR so force merging