Add ability to set subscription timeout via config

[NeoPhi]

It would be ideal if the middleware configuration and the defaultLinkCreator supported passing an override for the SubscriptionClient timeout instead of having it hard coded to 20000 as shown here:

https://github.com/prisma-labs/graphql-playground/blob/fa91e1b6d0488e6b5563d8b472682fe728ee0431/packages/graphql-playground-react/src/state/sessions/fetchingSagas.ts#L81

[lunaroyster]

Also here:

https://github.com/prisma-labs/graphql-playground/blob/824c7a57f0284f022726a8b8840aafc3e8720ccd/packages/graphql-playground-react/src/components/PlaygroundWrapper.tsx#L521

there's a 1000 ms limit to making the connection. I recently moved to the other side of the world, and was wondering why my subscriptions are broken 🤦

[fiLLLip]

https://github.com/prisma-labs/graphql-playground/blob/824c7a57f0284f022726a8b8840aafc3e8720ccd/packages/graphql-playground-react/src/components/PlaygroundWrapper.tsx#L521

there's a 1000 ms limit to making the connection.

I am facing an issue when using AWS Api Gateway with Lambda behind it. Cold starts sometimes exceed 1000ms, making the subscription fail. I think I'll create a PR for this.

[fiLLLip]

Actually, after doing some more research, it looks like the issue three-folded.

1. subscriptions-transport-ws uses backo2 to calculate timeout based on minTimeout and Timeout. minTimeout is set to 1000, and since this is first try it sets the timeout to 1000ms, even though we want to manually try again. Could be for internal retry or something, but if I click play 10 times the calculated timeout stays the same (1000ms).
2. fetchingSagas does not specify minTimeout (hence default 1000ms).
3. When not specifying a specific subscriptionEndpoint, the wrapper tries a connection to the regular enpoint, setting ws(s) as protocol, and timing out after 1000ms.

[guisehn]

This would help fix an issue where if the GraphQL server using subscription-transport-ws has a keepAlive set to anything above 20s, the subscription-transport-ws client used by graphql-playground kills the websocket connection after 20s.

[Shane32]

@sungam3r I was having trouble testing a new GraphQL.NET server implementation with a 25sec keep-alive timer because Playground (and/or subscription-transport-ws) apparently terminates connections after 20sec of not receiving a keep-alive packet (see above) -- but only if a keepalive packet has been received. If no keep-alive packets are received, it will keep the connection alive indefinitely. Moreover, it does not reset its timer if another packet has been received, so the server is required to send keep-alive packets continuously even with a steady stream of data.

The current GraphQL.NET Server implementation does not send keep-alive packets at all.

Note that Playground does not appear to support the newer graphql-ws package at all. See below:

• Ability to use graphql-ws instead of subscription-transport-ws #1291

Link to GraphQL.Net Server:

• https://github.com/graphql-dotnet/server