Handle Q.WATCH updates in a single event loop for Websockets

[psrvere]

Closes #1153

In PR #1090 Q.WATCH updates were handled by processQwatchUpdates run in a goroutine. Based on this review comment, this PR moves this handling to a single event loop. It

• adds subscriptionChan and subscribedClients to WebsocketServer
• runs listenForSubscriptions and processQwatchUpdates as part of WebsocketServer.Run()
• shutsdown above two goroutines through both shutdownChan (called by abort command) and ctx.Done channel

This PR also

• adds ReadResponse function in setup.go to read Q.WATCH updates
• adds two more integration tests TestQWatchWithMultipleClients and TestQWatchWithMultipleClientsAndQueries
• changes key names of all tests in qwatch_test.go to be unique so that there is no interference with other tests. Since cancelling subscription (Q.UNWATCH) is not supported yet, any following tests that changes the key also triggers Q.WATCH updates. This is a known issue and will be fixed as part of Add Q.UNWATCH for websocket #1154

This PR also fixes following bugs:

• Data races accessing conn.WriteMessage. Fix: added a mutex
• Any error in processing Q.WATCH updates resulted in returning processQwatchUpdates goroutine. Fix: It skips update when it can't process it and logs error.
• RunWebsocketServer in setup.go was relying on both cancelling parent context to shutdown queryManager goroutine and abort command to shutdown shardManager. Fix: Made it consistent - everythings is gracefully shutdown by abort command

[psrvere]

@lucifercr07 - Please review.

[arpit1912]

Have we done any benchmarking for the Q.Watch and do we want to check if we are not regressing anything with the above change?

[JyotinderSingh]

Hey @psrvere could you please resolve the conflicts?

[psrvere]

@JyotinderSingh - Resolved. Please review.

[lucifercr07]

Apologies if I'm missing something here, why do we need a separate go routine to listen for QWATCH subscriptions? Can't it be handled as part of websocketServer.ListenAndServe()?

[psrvere]

@lucifercr07 - ListenAndServe receives subscription request which is then handled by WebsocketHandler. It sends subscription event on subscriptionChan and a dedicated goroutine listenForSubscriptions receives the event and subscribes it.

Are you suggesting that we move the work done by listenForSubscriptions in WebsocketHandler?

I created it as a separate goroutine to separate the concern. Do you see any disadvantage in this?

[lucifercr07]

May be we can let WebsocketHandler do the subscription itself, it won't be an expensive/long-running op.
We've already separated processQwatchUpdates to a separate go-routine.
Commands other than .watch wouldn't be long-running generally and I feel a single go-routine would be enough to handle the clients.
Unless we see some latency issue may be we can avoid creating new go-routines.
Please let me know if I'm missing something here.