feat(ext): introduce extensions, starting with ConnectionInfo

[seanmonstar]

• Adds client::Builder::set_conn_info to opt-in to having connection
  info added to Responses from clients.
• Adds ext::ConnectionInfo that allows querying types (like a
  Response) for connection info.

Closes #1402

---

Still WIP...

[seanmonstar]

Some pieces of information would likely be very common. The two that come to mind are remote_addr and local_addr (is knowing the locally bound port sufficiently useful to be it's own thing)? However, a custom transport could have arbitrary information it could wish to advertise (like some details specific to a certain TLS implementation). I can think of a few ways that all this could be exposed:

1. ConnectionInfo + optional "extra" info in extensions

Have the "common" information be specific fields, and allow a user to get them from a Response by the API exposed here, ConnectionInfo::get(&res). The "extra" custom transport data would just be available through the normal res.extensions() API.

• Pros:
  • It's very likely most transports can set the common data, like remote_addr, and so if that is all a user is interested in, then changing transports won't affect the existence of the values.
• Cons:
  • If a transport can provide both the common info, and wants to provide extra info, it results in multiple allocations, storing both Box<ConnectionInfo as Any> and Box<SomeTransportExtra as Any> separately in the extensions.

Example:

// a transport:
let info = Connected::new()
    .remote_addr(remote)
    .local_addr(local)
    .extra(RustlsExtraSomething::from(&conn));

// getting from a Response
let common = hyper::ext::ConnectionInfo::get(&res);
println!("remote={:?}, local={:?}", common.remote_addr(), common.local_addr());
let extra = res.extensions().get::<RustlsExtraSomething>();

2. A single custom "extra" info contains all the values a transport can provided.

Do away with the ConnectionInfo type proposed here, and just have all info from the transport exist as a single value in res.extensions().

• Pros:
  • Reduces the amount of allocations needed to provide transport info in extensions to just 1.
• Cons:
  • Changing transports means needing to remember to change what type is fetched from extensions.

Example:

// for a transport
let info = Connected::new()
    .extra(RustlsExtraSomething::from(&conn));

// getting from a Response
if let Some(extra) = res.extensions().get::<RustlsExtraSomething>() {
    println!(
        "remote = {:?}, local = {:?}, cert = {:?}",
        extra.remote,
        extra.local,
        extra.cert,
    );
}

[seanmonstar]

Alternative 2 is explored in #1594.