move slider guis to meshcat about manipulation HOT 2 CLOSED

Another alternative has always been to avoid the zmqserver. I have a working version of meshcat visualizer in python that relies only on ipython kernel comms as the transport. That works great on local machines, but not on colab / deepnote (both of which use a custom kernel implementation).

But perhaps I should consider a visualizer that hosts the websocket connection directly (as zmqserver does now). This would be instead of kernel comms, would have the advantage that it would work outside of jupyter, but would still cut out the zmq layer. This feels like perhaps the best solution. There are still many decisions to be made (do I support multiple clients? do I store the scene tree on the server and allow a new client to get the history, or act more like drake visualizer and require the viewer to connect before any important message is sent?).

Here's a burn-down list for this version

• Spike test running zmqserver in the main jupyter notebook (not as subprocess). Verify I can still connect.
• Spike test the WebSocketVisualizer case in python, taking the easy answer to all of the interesting questions (single client, no memory).
• WebSocketVisualizer should get instantiated once (at the top of the notebook), and we pass a raw pointer or owned Pointer to the meshcat visualizer system. Perhaps it can even be a direct stand-in for the current visualizer. This is important so that users don't have to re-open their visualizer for each simulation.
• Spike test a C++ version of the WebSocketVisualizer.

from manipulation.

I've decided to run with the Meshcat in C++ solution for this. Closing this since I've moved the discussion to RobotLocomotion/drake#13038

from manipulation.