abstract out NetworkStreams

[seanmonstar]

@reem here's what I'm thinking to support arbitrary underlying Streams. Being generic removes the hit of a dynamic lookup, but can also be less ergonomic. Though, with the default type parameters, a Server, or Request, etc can still be used, with HttpStreams.

fixes #5

[reem]

I quite like this as a solution, but I'm also wary about how this makes impls for Handler more complex. I think it's a worthy tradeoff, but it's worth consideration. The second problem is that helpers which receive Request and Response will likely just use Request and Response, inadvertently making them unusable with alternative streams.

[seanmonstar]

Yea, both of those problems crop up. Is there some other way to do this?

[reem]

I think not. That dynamic dispatch is so much more ergonomic is, in my opinion, a slight problem in rust today. The only way to make this really work would be to remove the default type parameter in everything except Server.

[seanmonstar]

So, make everyone deal with the generics?

It's probably worth comparing benches... the only other way would be to accept a Box<Reader> and Box<Writer> in the constructors, right? I have not looked into DST at all, but that recently landed, and allows having Trait objects without indirection...

[reem]

Benchmarking dynamic vs. static dispatch here would probably be wise as it would let us know if this is even worth worrying about. If we could get static dispatch with dynamic-dispatch-like ergonomics, that would be even better.

[reem]

Merged as part of #29