move crypto provider installer to be called once

[Oscar-Pepper]

this PR must be followed by an addition to zingo-mobile rust to also call this installer on app launch

[juanky201271]

I added the FFI function in zingo-mobile:
zingolabs/zingo-mobile@62d68d7
And it's working, no run-time error about the Crypto Provider.

[fluidvanadium]

i am proud of these sync tests. i understand that they have variable run time, but i do not understand why they would be ignored

[nachog00]

Whats our stance on expects and unwraps? Do we allow them in tests only?
@zancas @Oscar-Pepper

[Oscar-Pepper]

i am proud of these sync tests. i understand that they have variable run time, but i do not understand why they would be ignored

as you said, we cant have tests unignored that are guaranteed to slow down test run time, they will just get ignored some time in the near future anyway and cost a load of CI / local test developer time. this is what darkside is for, we have chain load framework. the only limitation I am aware of is transparent

[Oscar-Pepper]

Whats our stance on expects and unwraps? Do we allow them in tests only? @zancas @Oscar-Pepper

unwraps are test-only. expects can be acceptable in production with a message that eludes to why it should NEVER panic.

[zancas]

In order to guarantee non-panic on an expect in production, we'd need to add wrapping correctness guarantees. That's not a proper effort for a developer unless they're already expert in the code base.

Please do NOT add expects to production code.

[zancas]

i am proud of these sync tests. i understand that they have variable run time, but i do not understand why they would be ignored

as you said, we cant have tests unignored that are guaranteed to slow down test run time, they will just get ignored some time in the near future anyway and cost a load of CI / local test developer time. this is what darkside is for, we have chain load framework. the only limitation I am aware of is transparent

I disagree. This is clear evidence that we do not have sufficient resources allocated to CI. We should not degrade our test quality because the free tier of github runners is too slow. That's the wrong direction. We need to invest in test infrastructure.

[zancas]

Alright I added some non-blocking comments.

[zancas]

Given @juanky201271 's test, and caveats about upgrading infrastructure.. I approve.