Makes builds simpler cause we don't have to track the Rust versions netsim builds on. Now it's supposed to build on all latest stable Rust 2018 edition versions.

Say I have this code snippet:

#[macro_use]
extern crate net_literals;
extern crate netsim;
extern crate tokio_core;
#[macro_use]
extern crate unwrap;

use netsim::{node, spawn, Ipv4Range, Network};
use tokio_core::reactor::Core;

fn main() {
    let mut evloop = unwrap!(Core::new());
    let network = Network::new(&evloop.handle());

    let server_recipe = node::ipv4::machine(|ip| {
        println!("[server] ip = {}", ip);
    });
    let (spawn_complete, _ipv4_plug) =
        spawn::ipv4_tree(&network.handle(), Ipv4Range::new(ipv4!("78.100.10.1"), 31), server_recipe);

    unwrap!(evloop.run(spawn_complete));
}

Which is not doing much, just spawning a single IPv4 machine. In such case maybe I'd like to assign a specific address to my machine. But if you run this code, netsim panics because of https://github.com/canndrew/netsim/blob/master/src/range/v4.rs#L112 Is there any particular reason we don't want to allow this behavior?

Static IPs also might be useful when we connect 2 nodes with router, then we don't need to exchange the IP addressess - less code in tests :)

netsim still uses an old version of Tokio (before Tokio reform). That requires me to depend on multiple versions of Tokio. I'll attempt to revive the new-tokio branch and update to the latest tokio version.

I was playing around with different simulated NAT types to see what kind of port allocations are used with specific NAT types. As a result I came up with a couple of integration tests. So I thought that might add some additional value in documenting and testing the public API.

This PR adds helper methods Network::spawn_ipvx_tree(). So the API is currently

    let network = Network::new(&evloop.handle());
    let node_recipe = node::ipv4::machine(|ip| ());
    let (spawn_complete, _ipv4_plug) = network.spawn_ipv4_tree(Ipv4Range::default, node_recipe);

instead of

    let network = Network::new(&evloop.handle());
    let node_recipe = node::ipv4::machine(|ip| ());
    let (spawn_complete, _ipv4_plug) = spawn::ipv4_tree(&network.handle(), Ipv4Range::default, node_recipe);

Which seems to be more intuitive to me. See if you like it :)

Add CI scripts and fix clippy isues so that travis would pass :) Note that at this point CI will fail though. We also need to exclude linux namespace related tests.

After the user creates a bunch of devices and spawns them to the event loop there is no longer any way to destroy them and, in some circumstances, they will not destroy themselves automatically. Devices should probably be scoped.

Having separate spawn, device and node APIs isn't really necessary. The spawn API can probably be removed and merged into the device and node modules.

When cargo test finishes, threads that are created by netsim can linger on in the background, consuming resources. They should automatically be killed when the parent process dies.

I'm planning to implement the packet broadcasting. My guess is that it should be implemented in router. So I did some code refactoring and added tests to router to make future changes safer.

Latest mio version (0.6.16) depends on libc >= 0.2.42. I've tried upgrading libc to 0.2.43 which is the latest at a given moment. Unfortunately, some tests failed. But I noticed that tests pass with 0.2.42 so didn't do proper research what caused tests failure since this version satisfy my needs at this moment :)

The codebase seems quite dated, some maintainance tasks after a quick look would be:

• [ ] update dependencies
• [ ] migrate to new futures
• [ ] support async-std
• [ ] use thiserror

So with the latest tokio integrated (https://github.com/canndrew/netsim/pull/25) now it won't allow to spawn another tokio reactor when netsim is running. So smth like this is not possible:

use futures::future;
use netsim::{Network, node, Ipv4Range};
use tokio::runtime::current_thread::Runtime;
use unwrap::unwrap;

fn main() {
    let network = Network::new();
    let network_handle = network.handle();

    let node1 = node::ipv4::machine(move |ip| {
        println!("node1: {}", ip);

        let fut = future::ok::<_, ()>(());
        let mut evloop = unwrap!(Runtime::new());
        unwrap!(evloop.block_on(fut));

        future::ok(())
    });

    let fut = future::lazy(move || {
        let (spawn_complete, _ip_plug) = network_handle.spawn_ipv4_tree(Ipv4Range::global(), node1);
        spawn_complete
    });
    let mut evloop = unwrap!(Runtime::new());
    unwrap!(evloop.block_on(fut));
}

and results with an error:

thread '<unnamed>' panicked at 'Multiple executors at once: EnterError { reason: "attempted to run an executor while another executor is already running" }', src/libcore/result.rs:997:5

In most cases when we have futures code this should not be a problem. Although, I can see 2 cases where it will be:

1. when we have a piece of code that internally runs tokio reactor;
2. when we have futures that do not implement Send trait.

The first thing we could do here is at least document the situation. Another thing to consider is to provide a netsim machine node that runs on a forked process instead of a thread.

netsim is pretty heavily tied to linux-only APIs for creating namespaces. I need to find out what APIs (if any) exist on other platforms for doing the same thing. Finding out how docker is implemented on other platforms might be a good start.

The clone call which creates the network namespace fails on Travis with permission denied, even though it supposedly shouldn't need any special permissions on any recent version of linux. This needs to be investigated.