Support no_std in (most) crates

[daviddrysdale]

First, need a version of prost that includes danburkert/prost@fdf9fdf.

Then the obvious changes needed to make Tink no_std compatible would include the following (but there are bound to be others):

• Depend on core + alloc instead of std, and have a std feature for those things that definitely need std:
  • keyset I/O (both binary and JSON-based)
  • streaming AEAD
• Changes to use core / alloc types:
  • Box => alloc::boxed::Box
  • String => alloc::string::String
  • Vec => alloc::vec::Vec
  • std::sync::Arc => alloc::sync::Arc
  • std::fmt::* => core::fmt::*
  • std::collections::HashMap => alloc::collections::BTreeMap
  • std::sync::RwLock => spin::RwLock
  • std::convert::From => core::convert::From
  • Move TinkError to wrap something that just implements core::fmt::Debug rather than std::error::Error.

[daviddrysdale]

Key question: given that alloc would definitely be required, does (no_std + alloc) really give much advantage over std?

[tiziano88]

I think in practice it's only useful for targets that do not have std yet, but somehow have alloc already. My guess is that there are not many practical cases for this. Maybe for some embedded devices based on Arm or AVR?

[daviddrysdale]

(Answering my own question: core + alloc works on platforms that have memory, but don't have (say) filesystems, networking, thread scheduling, etc. So yes, it does open up a bunch of potential platforms that std would exclude.)