no_std support for all crates

[madsmtm]

Fixes #609.

Our dependencies need to support no_std Done:

• matches, support since version 0.1.9, see Make matches crate no_std compatible SimonSapin/rust-std-candidates#23
• unicode-bidi, support since version 0.3.6, see Add no_std support unicode-bidi#58
• unicode-normalization, support since version 0.1.13, see Add no_std + alloc support unicode-rs/unicode-normalization#55

As far as I can see there's a few ways to solve the std::net issue noted in the linked issue:

1. Use something like no-std-net on no_std targets. Since that library doesn't have a MSRV, we might need to define that no_std support doesn't guarantee a MSRV (until we find a more permanent solution).
2. Change the structure of Host to store custom ip address types, and return std::net types in functions (that can then be feature gated). Requires a breaking version.
3. Wait until the RFC is merged, implemented and stabilized, and wait further until they have been around long enough to be in our MSRV.

As far as I can see option 1 is possible now, and it could even (with a little more work on no-std-net beforehand) be possible to migrate away from once (if) the RFC is stabilized, all without breaking changes.

[MathiasKoch]

Could this PR be revisited, now that all the dependencies are merged?

[madsmtm]

I think option 1 described above is feasible: We'll use no-std-net until these parts of net becomes available in core (if they ever do). We can't guarantee an MSRV on no_std, because no-std-net should be kept up to date with the current standard library, and hence might not compile on older Rust versions.

Currently I'm waiting for no-std-net to become a facade to std, see dunmatt/no-std-net#13, and for it to update to the implementation from newer Rust versions, see dunmatt/no-std-net#14.

Once these are done, we'll probably need to convince no-std-net to not have differences to std::net (like their extra const fns). This is required so that if core::net ever happens, migration to that is possible without breaking changes.

And finally, we'll need a new release with these changes.

If you can get some traction on the linked PRs, then I'll be glad to give this some more work.

[bors-servo]

☔ The latest upstream changes (presumably #728) made this pull request unmergeable. Please resolve the merge conflicts.

[MathiasKoch]

What is the current state of this? It seems to have completely stalled, even though all the blockers seems to have been merged & resolved?

[madsmtm]

It has stalled mainly because I haven't received word from the maintainers on neither this nor #722.

In the meantime, a PR for changing the layout of the network primitives is almost merged, after that RFC 2832 should be fairly trivial to accept. A way forward once we get that is to use something like if_rust_version to optionally import these from core instead of std (and then, once our MSRV is high enough, remove the dependency on if_rust_version again).

[MathiasKoch]

Wauw, that is awesome news! 👍

[bors-servo]

☔ The latest upstream changes (presumably #783) made this pull request unmergeable. Please resolve the merge conflicts.

[madsmtm]

@domenukk rebased this in #831, given that they seem to want to continue on this work, I'll close this PR (though I'm willing to pick it up again if you'd like my help).

[domenukk]

@domenukk rebased this in #831, given that they seem to want to continue on this work, I'll close this PR (though I'm willing to pick it up again if you'd like my help).

Happy to work together on this in any case