If a crate has std set, it should enable std for all dependencies in order to
let them properly select which algorithms to use. Some crates fallback to
slower/worse algorithms on no-std.
Also more aggressively sets default-features = false leading to a *10%*
reduction in the amount of crates coordinator builds.
This will effectively add msrv protections to the entire project as almost
everything grabs from these.
Doesn't add msrv to coins as coins/bitcoin is still frozen.
Doesn't add msrv to services since cargo msrv doesn't play nice with anything
importing the runtime.
zstd was recommended for the base layer only, due to its CPU requirements. That
was a misreading on mhy behalf.
lz4 gets ~5% better compression than snappy with ~30% faster performance. zstd
does ~25% better than lz4 yet at ~30% of the performance.
* Move monero-serai from std to std-shims, where possible
* no-std fixes
* Make the HttpRpc its own feature, thiserror only on std
* Drop monero-rs's epee for a homegrown one
We only need it for a single function. While I tried jeffro's, it didn't work
out of the box, had three unimplemented!s, and is no where near viable for
no_std.
Fixes#182, though should be further tested.
* no-std monero-serai
* Allow base58-monero via git
* cargo fmt
lazy_static, if no_std environments were used, effectively required always
using spin locks. This resolves the ergonomics of that while adopting Rust std
code.
no_std does still use a spin based solution. Theoretically, we could use
atomics, yet writing our own Mutex wasn't a priority.
