Add ZIP 321 URI parser

[ccjernigan]

Is your feature request related to a problem? Please describe.

In order to support zcash/secant-android-wallet#134 and zcash/secant-android-wallet#202, we need a parser for https://zips.z.cash/zip-0321

Describe the solution you'd like

A parser has been implemented in Rust, so ideally the SDK would expose a Kotlin API for the app to consume this.

Implementation tips

• A new JNI interface needs to be written. Relevant files include sdk-lib/src/main/rust/lib.rs sdk-lib/src/main/java/cash/z/ecc/android/sdk/jni/RustBackend
• A new Kotlin API needs to be written. We can probably draw from sdk-ext-lib in the secant repo for some of these.
• Because Rust libraries require disk IO to load, the Kotlin API will probably need a companion suspend new(toParse: String) function so that it can be initialized. Longer-term, we might want some kind of preloaded SDK object to make this less gross.
• Looking at the existing implementation, this might be a place where we start to do something different. RustBackend needs a lot of parameters to initialize (e.g. context, database paths, etc) and many of its operations are stateful. Meanwhile, it seems like we have a need here for some simpler utility functions that delegate to the Rust native library which are stateless. It might be that we consider a separate set of StatelessRustBackend/StatelessRustBackendWelding or UtilityRustBackend/UtilityRustBackendWelding classes that don't require constructor parameters. Strong suggestions for the name don't exist yet. This Stateless version of the class can share the same instance of NativeLibraryLoader, although we might moving it elsewhere instead of RustBackend.Companion.rustLibraryLoader. There is an existing interface of Derivation used by DerivationTool which sort of has the same pattern.

[HonzaR]

Hi @ccjernigan, have you decided on the naming of the new stateless/utility RustBacked classes yet? I'm in favor of utility naming, because I assume there will be more utility methods added later.

[ccjernigan]

I don't really have a strong opinion—if you think utility works then that seems like a reasonable place to start. This particular class will be internal to the SDK, so as a non-public API we can rename or refactor it as we learn more about how it will get used in practice.

[HonzaR]

Solution to this issue depends on updating lib.rs library in the Android SDK project. Waiting for it then. https://github.com/zcash/ZcashLightClientKit/issues/335