Initial integration with ledger application

[neithanmo]

This draft PR introduces a foundational step towards secure hardware wallet support within zingolib by integrating a custom ledger application.

Changes

• Keystore Abstraction: Introduced a new abstraction layer, Keystore, as an enum with two variants: WalletCapability for the existing in-memory wallet functionality, and LedgerWalletCapability for the new ledger integration. This allows for seamless switching between wallet types and makes future extensions possible and easy.

• Ledger Wallet Capability: The LedgerWalletCapability encapsulates all interactions with the Ledger device, including transaction signing(not supported yet) and address generation.

• Support for Sapling and Transparent Addresses: The ledger application currently supports sapling and transparent addresses, orchard protocol is not supported yet by the ledger-app.

Challenges

• Integration with In-memory Key Architecture: Adapting the ledger's secure key management approach to fit within zingolib's architecture, which currently relies on in-memory keys, poses a significant challenge. This required careful design to ensure that cryptographic operations are executed on the Ledger device, with zingolib managing only the operations that do not involve direct access to private keys, usually done through the TryFrom trait.
• Partial Address Support: Currently, the integration does not support orchard and unified addresses. The support for Orchard is not part of the scope of implementing this feature in zingolib but in the ledger-app.
• Data storage: Currently we are unable to read address data from wallet.dat file which is used to store important metadata like addresses and key parameters. This is due to the way the ledger app operates.
• ** Understanding zingolib architecture:** The current integration effort can be improved by a better understanding of the zingo architecture to ensure a seamlessly integration that would facilitate further integration of new features.
• Types differences: There are some conflicts between our Rust library and zingolib, the differences are more related to versioning and API compatibility.

There are some TODOs in the code and comments explaining the reason. This initial integration is still not functional, in order to get there more changes have to be done in:

• Defining how many metadata file the app supports and if differentiating from in memory or ledger-app ones is desirable.
• Proper changes on the UI
• Add support for sapling addresses
• Transaction signing would possibly require adding another abstraction, which for the ledger app is provided via ledger-zcash-rs
• Modifying ledger-zcash-rs library, in order to use raw data, could make easy further integration efforts, decoupling other libraries and relying on simple conversion, for example: PublicKey::from_slice(), and so on.

[fluidvanadium]

This is on my radar.

[zancas]

We've consulted with ZonDax and this work is largely obsolete. Is there important code to preserve @neithanmo ?

[pacu]

Is this fully outdated or is this just hard to rebase?

[neithanmo]

@zancas it is outdated, but the general integration idea holds, however this would depend on recent development the structure/design might be now outdated and could not be the best integration approach

[pacu]

I'm giving it a go to see if I can bring this to life in a newer branch

[zancas]

Superseded by #1352