feat: add websockets for dotbot commands

[WilliamTakeshi]

Update all commands to also have a websocket variant.

This makes us sending commands to hundreds of dotbots almost instantly. Before we needed to wait a connection from the pool, reopen, send the message, close it, etc.. It was slow for when the number of bots >100

[codecov]

Codecov Report

❌ Patch coverage is 80.83333% with 23 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.02%. Comparing base (12a6e1e) to head (f3501cd).
⚠️ Report is 7 commits behind head on main.

Files with missing lines	Patch %	Lines
dotbot/examples/charging_station.py	33.33%	10 Missing ⚠️
dotbot/websocket.py	42.85%	8 Missing ⚠️
dotbot/tests/test_experiment_charging_station.py	80.76%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #201      +/-   ##
==========================================
+ Coverage   79.27%   81.02%   +1.74%     
==========================================
  Files          21       26       +5     
  Lines        2157     2640     +483     
==========================================
+ Hits         1710     2139     +429     
- Misses        447      501      +54     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[aabadie]

Nice, but this doesn't solve the polling strategy that is used to update the status of all robots, right?

[geonnave]

Cool! Did you notice any speedup improvement? (More than 200 bots possible?)

Agree with @aabadie's comment, maybe you could have the example code have a callback that receives ws updates (per-robot updates would be ideal[1]) and writes them to a thread-safe list or dict.
The controller side could publish the list of bots to ws every X ms.
It can be a future PR.

[1] per-robot updates would maintain the whole architecture in a granular upstream flow of information: robot[i] -> mari-gw -> dotbot-controller -> example code. this would minimize latency across the system and improve consistency between the state of the example code and real robot behavior.

[WilliamTakeshi]

Nice, but this doesn't solve the polling strategy that is used to update the status of all robots, right?

Yes! Dotbot polling only happens once per control loop, while sending commands such as waypoints or rgb_led scales as O(n) with the number of robots.
I focused this PR on improving the latter, since it was the main bottleneck on the requester side.

[aabadie]

Would it be possible to add a test function for this new endpoint? server.py is 100% covered by test (there are not so many modules in this case, so let's not break that one ;) )

[WilliamTakeshi]

Good call! Testcases added on:

63c4bfb (this PR)
f3501cd (this PR)

[aabadie]

Thanks for adding the tests. I believe this is ready to go!