Merge juniper_graphql_transport_ws and juniper_graphql_ws crates (#1022)

[tyranron]

Part of #1022
Resolves #1186
Follows #1158, #1191

Motivation

Despite the raised concern for the initial implementation #1158 (comment):

A common use-case is for servers to support both simultaneously and negotiate the correct protocol to use on each connection, as discussed in seanmonstar/warp#760. To support that use-case, we can't force the users into one or the other at compile-time.

I also think the changes, while relatively minor, are pervasive enough that it makes switching between the protocols via conditionals very messy and hard to follow.

Integration of both protocols into a single crate showed, that fully separate crates (and therefore, types) introduce integration problems, which are resolved by reusing same types in both crates.

Following this, as we aim to support both protocols in our HTTP integration crates, both juniper_graphql_transport_ws and juniper_graphql_ws crates are always used and depend on each other, which makes a little sense to support them a separate crates.

Solution

Instead, it's enough to keep only one juniper_graphql_ws crate, where support both protocols via additive Cargo features. This will simplify maintenance and usage costs, while allowing to reuse similar types naturally, giving the desired level of polymorphism for supporting both protocols at the same time.

Checklist

• Tests are updated
• Documentation is updated
• CI is updated
• CHANGELOGs are updated

[tyranron]

@ccbrown since you're the original author, would like to see any comments on this before merging.

[ccbrown]

This looks good to me! I just have one non-blocking question.

[ccbrown]

Why gate these behind features at all? The modules for these are small and don't pull in additional dependencies. Unless I'm missing something, as a user I'm not sure why I would ever want to explicitly enable or disable these.

[tyranron]

@ccbrown I was thinking that some people may want to opt-in for the concrete protocol version and don't consider another one at all, thus avoid increasing compilation times and auto-completion pollution in any way.