feat: rust key derivation

[bkioshn]

Description

Implement Cardano key derivation using BIP39 mnemonic
The logic is written in Rust and expose to Flutter using the help of flutter_rust_bridge

Related Issue(s)

#1012 #1094

Description of Changes

Main functions

1. Given mnemonic and passphrase, generate an extended private key
2. Given extended private key and derivation path, derive a new extended private key
3. Given extended private key, derive the extended public key
4. Given extended private key, and data, sign the data to produce signature
5. Given extended private key, data, signature, verify the signature
6. Given extended public key, data, signature, verify the signature
7. dropping the extended private key (zeroing)

• Thread pool handling is included
• Simple return type eg. [u8; 96] is used so frontend can handle easily

Other

• simple.rs is removed
• Auto generated file for rust (frb_generated.rs) is ignored

Please confirm the following checks

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream module

[github-actions]

✅ Test Report | ${\color{lightgreen}Pass: 320/320}$ | ${\color{red}Fail: 0/320}$ |

[dtscalac]

As a general rule, we should NOT be embedding autogenerated files inside the git repo.

* How are they generated?

* Do i need to read a book about how to re-generate them if the bridge tools are updated?

* Do i need to update the Rust code independently of the dart code, or is it generated together?

* What else would I need to know to maintain this?

All autogenerated files should, ideally:

1. Be in a .gitignore file so they are never committed to the repo. (And the .gitignore should have a comment explaining this),

2. In CI, they are generated as part of the build, every time, with the version of the tools fixed in CI.

3. If they are needed locally, an Earthfile or Justfile can be used to generate local versions for testing (this needs to be documented).  Ideally this uses the same version of tools fixed in CI, so its better if its built with an Earthfile, but a Justfile could run earthly to do this.  I should not need to install any tools to do this autogeneration outside of Earthly, or to develop with this.

As we add more rust bound libraries, the maintenance burden of ensuring these bindings are always up-to-date will become overwhelming, and slow down development.

For apps and internal packages this is true however publicly exposed packages (i.e. via pub.dev) DO include the auto-generated files because developers who use them assume they will work out of the box without any extra steps. Otherwise the package would be unusable without forking it, generating these files and making the app talk to the forked version.

catalyst_key_derivation is going to be published on pub.dev because it's needed for catalyst_cardano_serialization which has been published already. The catalyst_cardano_serialization provides RBAC stuff and needs key derivation and signing which key_derivation package provides.

For example, the json_serializable is one of the most popular code generators. Here are the packages that depend on the json_serializable: https://pub.dev/packages?q=dependency%3Ajson_serializable. All of these include the auto-generated files in git.

TLDR: apps and internal packages may not include generated files but published packages must include them. Rust auto-generated files can be skipped but dart auto-generated files cannot be skipped.

[stevenj]

TLDR: apps and internal packages may not include generated files but published packages must include them. Rust auto-generated files can be skipped but dart auto-generated files cannot be skipped.

Understood, but we need to clearly document how they need to be generated and updated. And we should have a CI check to ensure they are not out of date.
They are probably not as bad as the API auto-generation because they will not be changing often.
Also, when your working on the API's you know your working on the bridge, its not a side effect.

[github-actions]

✅ Test Report | ${\color{lightgreen}Pass: 320/320}$ | ${\color{red}Fail: 0/320}$ |

[github-actions]

✅ Test Report | ${\color{lightgreen}Pass: 320/320}$ | ${\color{red}Fail: 0/320}$ |

[github-actions]

✅ Test Report | ${\color{lightgreen}Pass: 320/320}$ | ${\color{red}Fail: 0/320}$ |

[github-actions]

✅ Test Report | ${\color{lightgreen}Pass: 320/320}$ | ${\color{red}Fail: 0/320}$ |

[github-actions]

✅ Test Report | ${\color{lightgreen}Pass: 320/320}$ | ${\color{red}Fail: 0/320}$ |

[github-actions]

✅ Test Report | ${\color{lightgreen}Pass: 320/320}$ | ${\color{red}Fail: 0/320}$ |