[WIP] Adding no_std support

[SzymonKubica]

What was added?

Added support for rbpf to run on no_std environments.

Why is it needed?

Using rbpf on targets without std support increases compatibility of the crate.
A more high-level motivation is that running eBPF VMs on microcontrollers is an interesting way of performing over-the-air
updates of business logic deployed on IOT devices. It also allows for compartmentalization of multiple programs deployed on a single device. I'm currently working on my Master's project which aims to implement a system for running eBPF programs on low-end microcontrollers in RIOT OS (can be found here).

Testing

Currently the code compiles on with both configuration options enabled.
Compilation for native can be tested using the default cargo build. The no_std port can be tested using

cargo build --no-default-features

Remaining items for the PR

• add no_std specific tests and some testsuite environment using an emulator.

Notes

1. For my project I'm currently using a more heavily-modified version of rbpf which has already diverged from the upstream repo.
   I decided to bring over the no_std support changes back to this branch. This was because they are fairly easy to isolate and the additional changes that I have made might not be applicable to the general intended use-cases of rbpf.

2. When implementing the no_std port, I used this guide It seems to work well, however I realise that it introduces a somewhat bespoke way of handling imports (with the new concept of stdlib module) which might not match the expectations of the maintainers of rbpf. I'm open to discussion as to how the conditional imports of different versions based on std/no_std setting should be handled. Currently they are isolated inside of three modules: with_std, without_std, with_alloc which reexport the required imports. A correct combination of those import files is then included in lib.rs depending on the configuration.

3. For instance, an alternative approach which doesn't require the bespoke modules is to always handle all imports conditionally like so:

#[cfg(feature = "std")]
pub use std::collections::HashMap;
#[cfg(not(feature = "std"))]
pub use alloc::collections::BTreeMap as HashMap;

This approach has an advantage of not requiring additional files to correctly reexport required modules. However the cost is that all imports of things that require an allocator e.g. Vec, String, would need to be duplicated and gated with the corresponding cfg annotations.
The biggest advantage in this case would be that the overall file structure of rbpf would remain unchanged so no_std could be supported with minimal intervention in the existing codebase.

[qmonnet]

Hi, and thanks!
Sorry for the delay, I meant to take a look last weekend but this slipped out of my mind 😬. I'll probably need a few more days before I have time to look into the details of your PR.

In the meantime, would you mind fixing the issue raised by the Appveyor workflow please (Windows)? Given that you use config(jit) instead of Windows-related configuration options, we no longer disable the JIT stuff on Windows, causing the tests to try to run with the JIT and fail on Windows.

Could you please also sign-off your commits?

[SzymonKubica]

Hi, thank you for looking into the PR. Please don't worry about the timeline / delays, I realise that it is a non-trivial change and requires time to actually look through all of this.

I will look into the appveyor issue on windows and make sure it gets fixed. I will also start signing off the commits from now on.
Thanks