Adding closeSocket method for finer control of socket handling

[nwang92]

I found that we don't need to recreate VsWebSocket since that class itself is just a wrapper around the actual QWebSocket pointer.

This should also closely mirror how the bridge devices execute heartbeats, which is:

• When not connected to a studio, use the POST API
• When connected to a studio, use the websocket

In practice, I'm seeing there is a small gap in behavior because of the non-blocking nature of these QT libraries. For example, I added this line:

qDebug() << now << "Websocket valid" << m_heartbeatWebSocket->isValid();

to confirm the behavior above, and what I saw was:

<after opening the app>
"2022-06-24T16:26:03Z" Websocket valid false

<after joining studio>
...
step 7
    UdpDataProtocol:run1 before mJackTrip->parseAudioPacket()
Received Connection from Peer!
step 8
Received connection
UDP waiting too long (more than 30ms) for 54.215.67.209...
AutoQueue: 13

"2022-06-24T16:26:13Z" Websocket valid false
"2022-06-24T16:26:23Z" Websocket valid true
...
"2022-06-24T16:31:03Z" Websocket valid true
"2022-06-24T16:31:13Z" Websocket valid true
"2022-06-24T16:31:23Z" Websocket valid false 
"2022-06-24T16:31:33Z" Websocket valid true

...
<after leaving studio>
Stopping JackTrip...
sending exit packet
JackTrip Processes STOPPED!
---------------------------------------------------------
"2022-06-24T16:31:43Z" Websocket valid false
"2022-06-24T16:31:53Z" Websocket valid false

The line "2022-06-24T16:31:23Z" Websocket valid false should never be false, but the remote host breaks the websocket connection every 5m and although we reopen this socket connection, it takes time to set that up. I'm not sure if there's a way we can make this openSocket blocking or not.