Allow configuring a serializer and support binary data

[pojiro]

This PR tries to implement handling binary data feature, relates to #28 and #53.

This may include implementation and testing omissions due to a lack of understanding of the Slipstream overview.

Roughly, I first prepare the Serializer behaviour as Slipstream.Serializer, then implement client side silializer which corresponding to Phoenix V2 JSON serializer.

I followed the TDD, first added tests to synchronicity_test.exs and then implemented to satisfy them.

This PR is intended to be the base of implementation and should be modified to fit this project.

[pojiro]

Currentry I refactor lib/slipstream/connection/impl.ex, could you wait a little longer for the review, till it will be finished.

finished.

[pojiro]

@the-mikedavis Could you review this when you are free?

[the-mikedavis]

Thanks for the PR! I am away for a few weeks but I will give the changes a proper look when I get back.

[pojiro]

I fixed the credo issue. I will fix the following coverall issue later, thanks.

https://coveralls.io/builds/60510158/source?filename=lib%2Fslipstream%2Fserializer%2Fphoenix_socket_v2_serializer.ex

[pojiro]

Coverall issues are fixed, thanks.

[the-mikedavis]

This looks great! The only thing that worries me is the change from json_parser to serializer for configuration: that's a breaking change so we'd need to cut a 2.0.0 release. Instead could we keep the json_parser option around and mark it as deprecated using the :deprecated NimbleOptions option and use that as a default value in Slipstream.Serializer.PhoenixSocketV2Serializer rather than hard-coding Jason?

Alternatively we could keep the json_parser option around without deprecating it so that it would be easy to switch out that module without re-implementing the serializer, and document that it has no effect if using a custom serializer

[pojiro]

Thanks for your review! I added one commit for it. This commit make that

• user can change json_parser as before
• there is no need to deprecate json_parser config

How about this?

[pojiro]

This makes a breaking change for users who use custom JSON parser which doesn't have decode!/1.

before this PR

The original line is not fit the actual codes. The codes expected encode!/1 and decode/1. This was just document error. Custom JSON parser users know that and implement them to fit the codes.

after this PR

This PR codes expect decode!/1 for json_parser. So this change should be written in CHANGELOG.

[the-mikedavis]

Looks great, thanks for working on this!