feat(pool): add a Singleton pool type

[seanmonstar]

This creates a Singleton pool service which wraps an inner make-service, and queues up all calls while waiting for the one instance to be created, and then hands out clones. This pattern fits HTTP/2 well.

The current implementation mirrors much of how the legacy pool handles connecting with HTTP/2 prior knowledge.

Closes hyperium/hyper#3953

[cratelyn]

this is really exciting work @seanmonstar! thanks for your patience in review, it took me a couple days to take a deep read through this.

broadly i believe this is already in tremendous shape. my primary concern is bounding the number of pending callers while waiting for the connection to be established.

besides that, i have a question about how this might be extended in the future to accommodate an Arc<T>-backed inner service. that is mostly a forward-facing design question rather than concern with this initial introduction to the client::pool module.

thanks for breaking this work out into distinct pull requests, and for the illustrative outline and examples in hyperium/hyper#3948.

[cratelyn]

something we may wish to add as a follow-on to this would be a similar "singleton" pool that is backed by an Arc<T>. upon my initial read, i was slightly surprised we weren't Arc<T>'ing the generated Service<T> to already.

as is, this calls mk_svc.call() once, but does result in multiple distinct copies of the M::Response service. an Arc<T>-backed singleton pool would be useful for services that are expensive to Clone.

i don't believe any of this blocks this specific change, but i'm curious to ask where we think it might reasonably live. ideally we could rely on a lot of this infrastructure, since 99% of it will be the same! 😸

[cratelyn]

modulo the note(s) on documentation comments, i think this looks great. i am excited to see this work move forward! nice work 🚀