Test in CI if the lib works in embedded

[RCasatta]

on top of #118

Test in CI if the lib works in embedded envs (it only builds because running would require virtualization over virtualization which I don't think is supported in github actions at the moment, cargo run works locally with qemu for arm)

Reveals issue with the way core is exported in impl_newtype! macro https://github.com/RCasatta/bitcoin_hashes/runs/2306757898?check_suite_focus=true

When fixing $crate::core in 40e9fb7 it creates an issue with the MSRV https://github.com/RCasatta/bitcoin_hashes/actions/runs/733467719 (works from 1.31)

Any idea how to be compatible with 1.29 ?

FIXED

[elichai]

Thanks, that's a great idea.
How do you think your way compares to https://github.com/rust-bitcoin/rust-secp256k1/tree/master/no_std_test (this runs on x64 and uses the linker to make sure libstd doesn't link in)

[RCasatta]

Oh, I didn't saw no_std_test in rust-secp256k1...

I think this way is more a concrete embedded situation (it's taken from the https://github.com/rust-embedded/cortex-m-quickstart). Advantages may be: enforced limited memory (UPDATE, maybe too limited! I noticed 64k wouldn't be enough for the secp256k1 allocation of 70k... UPDATE2: there are other supported machine instead of lm3s6965evb with much memory like mps2-an511) and the possibility to use real implementation for print to stdout and rng. While the downside is to require arm virtualization.

I think the important thing is to have one or the other (or even both if they provide differents check) in the CI

[RCasatta]

Any idea how to be compatible with 1.29 ?

Probably the best option is to have different MSRV for std (1.29) and no_std (1.36) since I think it's hard to do without alloc

(along the lines of rust-bitcoin/rust-bech32#51)

[RCasatta]

superseded by #122