Run-time problem in Android - `rustls` upgrade related.

[juanky201271]

History:

1. in some near past someone upgraded rustls to 0.23.12 if I recall correctly. This update have two new crates: aws-ls-rs & aws-ls-sys, AFAIK this crate rustls have 2 different cryptographic backends:
   • the old one: ring.
   • the new one: aws.

This upgrade introduce something new, When you use: ClientConfig::builder() -> https://github.com/zingolabs/zingolib/blob/dev/zingo-netutils/src/lib.rs#L109 for instance... before you have to choose one backend between ring and aws or select the backend by default CryptoProvider::install_default() which I believe is aws.

Nobody knows about this until now... I guess.

2. I had some issues cross-compiling zingolib, commit: https://github.com/zingolabs/zingolib/commit/6454707abf12671f8935c5937ba25e51ee2bace9 because of these libs from aws. I wondered what really will bring to us, and I find out...

3. I had the same error in both Platforms:

4. some research: I found this:

   
   Support for process-wide selection of CryptoProviders. See [the documentation](javascript:;). Note that callers of ClientConfig::builder(), ServerConfig::builder(), WebPkiServerVerifier::builder() and WebPkiClientVerifier::builder() must now ensure that the crate's features are unambiguous or explicitly select a process-level provider using CryptoProvider::install_default(). Otherwise, these calls will panic with:
   
   no process-level CryptoProvider available -- call CryptoProvider::install_default() before this point

We recommend that libraries rely on the process-level provider by default, and that applications use this new API to select the provider they wish to use.

Ref: https://mygit.osfipin.com/release/144217327

and this doc: https://rustls.github.io/rustls/prerelease/crypto/struct.CryptoProvider.html#using-the-per-process-default-cryptoprovider

and a poor example that how to solve this issue: https://github.com/zydou/arti/blob/c21370400bd52d670dcfac79b18901467d6ffa36/crates/tor-rtcompat/src/impls/rustls.rs#L103C9-L115C10

**NOTE: AFAIT this run-time error is related with the crate `zingo-netutils` -> `get_client` and this problem is 100% rust, nothing to do with cross-compiling because when you read the doc of this crate you realized you need to do something about the necessity of choose between `ring` or `aws`.**

@zancas are you able to use `get_client` from `zingo-netutils` with this zingolib commit: `https://github.com/zingolabs/zingolib/commit/6454707abf12671f8935c5937ba25e51ee2bace9`??????? I bet you can't...  :-D

[juanky201271]

I want to apologize in advance if I said something wrong or inaccurate... rust is not my area of expertise... We are totally blocked with this problem, we cannot test the App at all.

[juanky201271]

@nachog00 Are you working on this issue? If so, any update? Thanks in advance.

[nachog00]

I am So far i got the issue replicated and kindda solved it (i got it to run past the error). Right now I'm sorting out the specific changes that fix it.

[fluidvanadium]

1403 fixes in zingo-cli but likely not yet in zingo-mobile

[juanky201271]

I solved this in zingo-mobile, adding a new uniffi method: https://github.com/zingolabs/zingo-mobile/blob/7d736bdc0a250a94b2d95c43552d9530caa63af8/rust/lib/src/lib.rs#L303 and invoking it when the App is launching...