Put the client and firebase behind feature flags

[platy]

On top of #25 , this allows the crate to be used with neither async runtimes, and just convert between http_types::{Request, Response} and the web push types. This allows the user to select some 3rd runtime, to use a preferred http client or event to use in a blocking way. I've also put firebase behind a feature flag, although IMO we can remove it completely as chrome supports native web push now.

Included an example using a blocking client (ureq), unfortunately I can't find one which works with http_types. It uses futures::block_on and I believe no threads are spawned, but I don't know how to test that.

The only measure of dependency complexity that I know is cargo tree | wc -l, and it is a big reduction to not include a runtime:

• rt-tokio : 297
• rt-async-std : 285
• none : 168

[pimeys]

Ah, this looks great. Yeah, futures::block_on should block the current thread and resolve the IO by polling. Maybe check why fmt/docs are red in the CI and I'll merge.

[platy]

Sure! Also, what do you think about removing firebase? I've been using autopoll to successfully send pushes to chrome - I think the firebase API use here is deprecated. Also, if we remove it it makes the response conversion function simpler as it doesn't need to know the service type.

[pimeys]

I don't know anything about the current state of web push. If it works without, GREAT! One less Google service to use is always good news.

[pimeys]

And, it's always better to remove code than to add it. So, instead of feature flags, I'd just remove the whole thing completely.

[platy]

Done!

I saw that there was handling for a android.googleapis.com service, my guess is that it doesn't need firebase, but I don't know what it is, so I can't be sure of it.

[pimeys]

Yeah, we can have an extended period without releasing a new version or do alphas. So many things changing and I'm not sure is anybody using this crate anymore in places where we need to be really fast...