Add GraphQLWs subscription transport option for GraphiQL

[Shane32]

This feature is necessary in case the user has disabled the subscription-transport-ws package/protocol, which is desirable if you need 'secure' keep-alive packet functionality.

[Shane32]

@gao-artur What do you think? It currently loads both protocol implementations but only initializes the one its configured to use. I could make it only load the one it needs, but at that point maybe two different cshtml files would be better -- but that's more maintenance, and I'd prefer to just have a single cshtml file to manage. I found the js code somewhere, changed it quite a bit, modified it so that non-subscription requests will use the regular fetcher (which supports headers) and stuff. Everything seems to work like it should -- (actually it works better than before, since now the stop button works to unsubscribe).

[gao-artur]

I'm sorry, but I'm a 100% C# backend rat, and I have zero knowledge of frontend and JS (I've been trying to avoid touching them my whole career).

[STRATZ-Ken]

Wanted to chime in here. I believe the ultimate issue for us was with the older technology this is what would happen. We send fairly large web socket messages. When people are on their phone then go to another website/close, the phone would leave an idle connection for some time. However we would continue to send packets over and over filling a buffer that could never be released.

This code above would allow us to make sure that the buffer is kept small/clean or force a disconnect. This is pretty common on newer phones to keep a semi-connection incase the user comes right back.