Generic HTTP/2 workers

[rslota]

This PR introduces a generic HTTP/2 workers that deduplicate lots of code from FCM and APNS workers. The FCM implementation is from #52 .
Also I've hanged HTTP/2 client library. This is due to fact that Kadabra is kinda slow and also, fails to deliver all messages when there are lot of streams open. In my load testing Kadabra showed many flaws, like dropped massages, corrupted connections, etc., while chatterbox is almost flawless (it need one small change: joedevivo/chatterbox#106).

This PR is more like "to discuss" and may require more work.

[hpopp]

Nice. I was thinking about this exact refactor the other day.

I still need to look things over but first things that come to mind:

We used chatterbox up until hex.pm banned all GitHub dependencies. I wrote kadabra as sort of a stop-gap measure until something better came along. I noticed someone finally posted chatterbox to hex, but we'll need to test. It looks like it has very few downloads.

If we do migrate back to chatterbox we also need to make sure heartbeat pings work. chatterbox doesn't keep connections alive on its own, and I remember having extreme difficulty getting it to send a ping manually.

[rslota]

Hi,

In regard to low download count: this is na erlang project and erlang world still either don't know about hex or simply don't use rebar3 that allow to do that. In my load testing I've tested several HTTP/2 client libraries and chatterbox is the only one that works stable and fast.
If you really need ping feature I can look into it and make a PR to chatterbox that enables that.

[rslota]

chatterbox ping, here you go: joedevivo/chatterbox#107

[asgoel]

@hpopp couldn't you also get around the chatterbox issue by not including it as an explicit dependency but forcing people who want to use pigeon to add it separately as a dep/application? There are definitely other libraries that do that as well to circumvent the hex.pm issue

[hpopp]

That workaround still feels hackish and goes against my general philosophy for published packages.

I wouldn't be opposed to some sort of configuration option that lets you specify the http2 client used. I'm not ready to give up on kadabra yet, but if others want to use chatterbox it should be perfectly acceptable.

[tsloughter]

I published chatterbox to hex and happy to keep cutting releases when updates you need get accepted into chatterbox.

[hpopp]

Awesome! The only outstanding required feature is joedevivo/chatterbox#107. APNS will drop long-running connections if there's no activity.

[tsloughter]

Ah yea, merging that now.

[tsloughter]

Merged and I published version 0.4.2 to hex.

[hpopp]

Wrote an initial implementation of client adapters at #67. From my testing so far both of the kadabra and chatterbox adapters work fine.

I'm starting to lean more toward making chatterbox the default adapter. I want to update kadabra to use :gen_statem and the Registry, but it will bump the minimum required elixir version to 1.4.

[asgoel]

@rslota any chance you can make this ping_interval configurable? some networks (such as AWS) require activity at a higher frequency so the ping has to be lower

[asgoel]

@rslota how stable is this code compared to master? wondering if i could switch a production app to using this vs kadabra

[hpopp]

Updated to v0.12.0 which allows optional chatterbox configuration. Check the README for details

[hpopp]

Closing with the published changes in v1.1