Non-fatal error handling

[mrtcode]

This is a possible solution to error handling in a non-fatal way.

• Now it never closes, but maybe on some errors it should?
• Error handling should be implemented to be convenient for client. Now it just sends an error event. Is it convenient?
• Tests that check socket close codes need do be updated accordingly.

[dstillman]

, code, message: (can always omit matching variable names now)

[mrtcode]

Ok, so write the new code in ES6 everywhere.

[mrtcode]

This checks for requestID for all client messages going through handleClientMessage, currently only createSubscriptions and deleteSubscriptions. If requestID exists, it's returned back with the response. Doesn't matter if it's an error response or success, all of them must return the requestID. And there always should be one response.

There are 3 exceptional errors that don't return requestID, because can't parse/validate:

• Message not provided
• Error parsing JSON
• Invalid requestID provided

Let's call those implementation errors. If a client is properly coded those errors shouldn't happen. Unless the data is corrupted while transferred, which should be fatal anyway. In those cases it would make sense to close the connection. Maybe that's the answer to the question which errors should be fatal and which not.

UPDATE:
Actually 4 errors. There is a message length check.

[mrtcode]

But actually 'action' not provided and Invalid action are also implementation (or data corruption) errors.

[mrtcode]

Removed requestID commit. Arkivo no longer needs this. If we will need this for other things we could return back this feature in future.

So what it does now is just instead of closing connection, it sends the error.

Also fixes bug which exposes 500 error even for non dev site.