Move cached-data-server and websocket-server to a functionality of an OpenRVDAS API implementation.

[webbpinner]

This may be too big a change but hear me out...

What uses the cache-data-server??? As far as I can tell only the Django-based web-client and the display widgets

What uses the websocket-server??? As far as I can tell only the Django-based web-client and the display widgets

I think I could make a good argument that the cached-data-server and websocket server are BOTH not used unless OpenRVDAS is controlled via web-interface and/or the operator is using web-based widgets.

If OpenRVDAS were to be deployed on a stand-alone deploy-able sensor package, like an AUV, subsea moring-based package, etc where only the DAS functionality was needed then the websocket server and cached-data-server would NOT be used.

Recommend moving the cache-data-server and websocket-server to be handled by API implementation.

Examples of data flow under this proposed change (assume there are 2 web-clients actively monitoring the server):

• Web-client 1 requests to change the mode of the server:

1. Web-client clicks link to change mode of server.
2. Web-server receives request from web-client, makes API call to logger-manager to change modes.
3. Web-server responds to all clients via websocket that there is a mode change pending.
4. Logger-manager completes mode change, makes API call to update the active mode in the data store (django)
5. Web-server notifies all connected clients via websocket that change has been completed, optionally if the mode change was unsuccessful the logger-manager submits an API call with the appropriate log message, which is committed to datastore, the web-server updates all clients via websocket that there was an error changing modes.