Have Buffer use default executor

[carllerche]

Buffer requires an executor to spawn tasks. Currently, constructing a buffer requires an explicit executor to be passed in. Instead, Buffer::new should default to DefaultExecutor.

Though, currently Buffer::new spawns the task eagerly in new, but often times the Buffer instance is created from outside of the runtime before, in which case DefaultExecutor won't work.

There would be a new constructor fn Buffer::new_with_executor (though, the name might be improved) that takes an executor.

Buffer should also be updated to avoid exposing the concrete task type that needs to be spawned. We can opt for the strategy described here.

[jonhoo]

I'll try to persist some of my thoughts from the Gitter about this change, and also how it interacts with #118.

The proposed solution here is basically:

struct Buffer<T, Request, Executor = DefaultExecutor>
where T: Service<Request>
{
    executor: Executor,
    worker: Option<Worker<T, Request>>,
    // ...
}

And then have poll_ready be:

fn poll_ready(...) -> ... {
    if let Some(w) = self.worker.take() {
        self.executor.spawn(w);
    }
    // ...
}

With #118, the T: Service bound on Worker has to become T: DirectService<Request> instead. To allow Buffer to wrap regular Services, we also provide a DirectedService<T: Service> wrapper that impl DirectService by proxying poll_ready and call to T and doing nothing for the other methods. But Buffer<T> must now have the bound T: DirectService<Request> if it is to contain the Worker instance. While the user can specify that type, they'll have to know about DirectService and the DirectedService wrapper, which seems unfortunate. I don't have a clean workaround for this that doesn't involve Boxing the Worker.

---

As for hiding the concrete task type that needs to be spawned using this approach, I'm not sure how the solution outlined there fixes issue I raise above? We basically already have the proposed wrapper type (Worker ~= MyLibTask), but this still doesn't hide Worker (due to the E: TypedExecutor<MyLibTask<T> bound). It also still reveals the T: DirectService bound, and the DirectedService wrapper, which seems unfortunate. I don't have a way of getting around that though sadly.

One alternative specifically for the DefaultExecutor case would be to have Buffer::new use future::lazy and return impl Future<Item = Buffer>. It's definitely a bit of a cop-out, but saves us from some of these thorny issues.

---

And finally, isn't it a little sad for Buffer to carry along an Executor? It probably doesn't matter too much for DefaultExecutor, but are there other Executors where this might be a problem?

---

Overall, I think we should probably wait to make this change until after #118 lands.