Add GlobalOnly Transport implementation blocking dials to private IPs

[mxinden]

Description

Upstream the Kademlia Exporter GlobalOnly Transport implementation to rust-libp2p.

https://github.com/mxinden/kademlia-exporter/blob/master/src/exporter/client/global_only.rs

Motivation

Allows denying all dials to non-public IP addresses. E.g. helpful as dialing private IP addresses can be seen as an attack by cloud providers.

See also #2824 (comment).

Requirements

1. No dependency on Rust nightly.

Open questions

Are you planning to do it yourself in a pull request?

No

[tcoratger]

@mxinden In the implementation you mention, there are few positions where is_global() function is used. For example, this one:

Some(Protocol::Ip4(a)) => {
    if a.is_global() {
        self.inner.dial(addr)
    } else {
        debug!("Not dialing non global IP address {:?}.", a);
        Err(TransportError::MultiaddrNotSupported(addr))
    }
}

Considering this PR, this function is notified as unstable. For that, we can use a #![feature(ip)] patch but this is not recommended on a stable version of libp2p. What do you think about that?

[dariusc93]

@mxinden In the implementation you mention, there are few positions where is_global() function is used. For example, this one:

Some(Protocol::Ip4(a)) => {
    if a.is_global() {
        self.inner.dial(addr)
    } else {
        debug!("Not dialing non global IP address {:?}.", a);
        Err(TransportError::MultiaddrNotSupported(addr))
    }
}

Considering this PR, this function is notified as unstable. For that, we can use a #![feature(ip)] patch but this is not recommended on a stable version of libp2p. What do you think about that?

We could extract the logic of the function into our own function to determine if an ip is global or not. We could probably even copy https://github.com/libp2p/rust-libp2p/blob/master/protocols/autonat/src/behaviour.rs#L611-L721 over into a GlobalOnly transport (or maybe into some utility module that autonat and the transport can share?)

[thomaseizinger]

@tcoratger We definitely need to avoid nightly.

I'd recommend we vendor the function in. The impl is not going to change because what is and isn't considered a global IP will be the same tomorrow and the week after :)

Thus, there is effectively no maintenance cost here.

@dariusc93 A shared module has the cost of a dependency which I'd like to avoid.

A private, internal function is a bit of duplication but we can remove that once it hits stable.