feat(client): Implement Tower's Service for Client

[davidbarsky]

This is relatively small. Open questions:

• Should this behind a feature flag?
  • Until DirectService is the default in Tower?
  • ...past that point?

I think additional middleware implementations should be tower-rs/tower-hyper, such as specific timeouts and retry policies. Building on that, I wonder if it makes sense to have a “batteries-included” middleware crate—I know my employer has specific best-practices around retries that are typically followed-company wide, but that probably doesn't belong in that crate.

Still to do before merging:

• Documentation and examples for Tower in Hyper

[davidbarsky]

Oh, I also have no idea how to tackle replacing Service's Service impl. That's a bit... beyond me.

[seanmonstar]

The possibility of needing to go to tower_service = "0.3" relatively soon worries me some...

[sfackler]

New cargo can handle that by supporting multiple optional dependencies of tower at different versions. Might be worth doing this in a separate crate with a newtype wrapper until hyper can bump its minimum supported Rust version to 1.31.

[seanmonstar]

@sfackler wait what? Got an example, or a link to something I can read more about?

[sfackler]

Here's an example in rust-postgres: https://github.com/sfackler/rust-postgres/blob/master/tokio-postgres/Cargo.toml#L58

While we don't do it yet, we could have an equivalent bit-vec-06 or whatever dependency that works side-by-side with the existing one.

[davidbarsky]

I'll close this ticket until tower-rs/tower#136 is resolved. I think it's best that any experimentation along these lines occur in tower-rs/tower-hyper.