[WIP] Full WASM support (tracking PR)

[gnunicorn]

Switching on WASM support for the libp2p-package (rather than -code) to
track, which parts still need to be worked on to get full wasm-support going.
Add fixes to it as we go along.

[tomaka]

There's an open question about platform-specific features. Some elements cannot be used on some platforms, namely Unix sockets on anything else but Unix, and TCP/UDP/etc. on asm.js/wasm.

Therefore:

• Should we disable these features at compile-time on platforms that don't support it,
• Should we return an error at runtime instead?

Both options have their advantages and inconvenient.

[gnunicorn]

I want to make the point, that I was able to make it compile with wasm32-unknown-unknown last night, including for libp2p-secio and with ring - however, I doubt this actually works, as most ring crypto will only be compiled to linux x86 ASM format at the moment...

[gnunicorn]

note to self. Parts of ring we actually use at the moment are all in secio. Namely we use:

• ring::digest::{SHA256, SHA512, Context, digest, Algorithm},
• ring::agreement::{Algorithm, agree_ephemeral, ECDH_P256, ECDH_P384, EphemeralPrivateKey, agreement}
• ring::hmac::{SigningKey, VerificationKey, verify, sign, SigningContext}
• ring::signature::{Ed25519KeyPair, RSAKeyPair, verify, ED25519, RSASigningState, RSA_PKCS1_2048_8192_SHA256, RSA_PKCS1_SHA256}
• ring::rand::{SecureRandom, SystemRandom}

Though rust-crypto-wasm supports SHA-digest and ED25519, neither this crate nor the RustCrypto project have RSA or ECDH support yet. But there is a RSA crate in the works.

[tomaka]

See also openethereum/parity-ethereum#7915

[gnunicorn]

There is also the possibility to use WebCrypto in wasm, it supports all the crypto we require for secio. However webcrypto is async and returns promises, while currently ring is sync. But that sounds like a feasible thing to do.

[tomaka]

cc-ing #806

[tomaka]

The state of wasm after #806 is that the library compiles fine with cargo web build (so wasm32-unknown-unknown). Trying to use emscripten fails because i128 are not supported.

However trying to compile a binary fails because apparently the cc-rs crate erroneously compiles C files for Linux instead of WASM, and thus the linker yells at us.
We have one single piece of C code, which is the clear_on_drop crate (an indirect dependency).