Feature: Allow user to initialize Client with pre-existing HttpClient or make HttpClient into trait

[DoumanAsh]

For advanced use cases it would be convenient to allow user to pass their own hyper's Client instead of having library to create it
This is mostly useful for complex application that communicates with different APIs.
Since hyper's Client is thread safe, it would make sense to allow user to pass it directly.

Considering internally, it already boxes request send, it could be even made into trait instead of using concrete client (no need for async-trait since it is just one function to return future)

If you're agree to accept PR I can also try to implement it myself

[arlyon]

Hi! Thanks for reaching out :)

I actually have been working on trait-ifying the project however it is slightly more complicated as I'd like to remove the sync/async feature flag altogether so have been experimenting with GATs to allow the client to define its async-ness. After a few iterations I believe I am getting close to a 'good' solution for when GATs land in stable in a few months :)

That said, I would be open to any PRs that experiment in this direction (traits, GATs, etc). More solutions are better than none until we have one that looks good. Maybe as a stop gap, a PR to allow supplying your own client w/ the current feature-flagged setup would be a good first step.

[DoumanAsh]

if you want good solution you will probably need specialization rather than GAT alone.
In first place current trait system is unable to distinguish between sync and async(you would base it on Future trait) without enabling specialization.
sync client can just use core::future::ready to produce result as there is no asynchronous computation.

GAT can remove need for ugly Box, but it is still must be Future unless you can specialize your implementation to distinguish between Future and non-Future types

But if simple approach by passing hyper's client is ok, then that's more than enough for my needs.
I'll prepare PR on next week.