feat(api): add a stateless command to control the status bar

[fsinapi]

Overview

This PR adds a command to control the status bar to run a few select animations on it. The animations available are expected to be the ones that the app may want to remotely trigger the robot server to run based on some design workflows.

The animation will NOT run if a protocol is currently running. This is mostly handled implicitly because the stateless commands can't run while a protocol is running, but we also want to block out the animations from running when a protocol is completed but not acknowledged (status bar is either green or red for success or failure). To accomplish this, the command checks if the current status bar state indicates that it is being controlled by the background Light Control Task.

Test Plan

Used the POST /commands endpoint to send setStatusBar commands.

• When the robot is idle, you can send any of the enumerated options and they'll animate the bar appropriately
• When the robot is in the middle of a run, the endpoint either gives an error code (if the run is actually running) or silently fails to run the command (if the run is waiting to be acknowledged). This is as expected.

Changelog

• added a StatusBarHandler class to be able to mock out status bar setting
• added StatusBarHandler to the protocol engine
• added a setStatusBar command to the protocol engine
• updated protocol engine json schema to add new command

Review requests

• Is this the correct way to have an enumerated string parameter for a command? I copied what the moveToMaintenancePosition command does.
• I regenerated the schema after these changes but did I miss anything for integrating the command?

Risk assessment

Pretty low as long as all the CI for the protocol engine keeps working.

[codecov]

Codecov Report

Merging #12890 (f6c9bb2) into edge (56897a1) will increase coverage by 0.33%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             edge   #12890      +/-   ##
==========================================
+ Coverage   73.01%   73.34%   +0.33%     
==========================================
  Files        1516     2343     +827     
  Lines       49686    64832   +15146     
  Branches     3037     6963    +3926     
==========================================
+ Hits        36277    47551   +11274     
- Misses      12943    15629    +2686     
- Partials      466     1652    +1186     

Flag	Coverage Δ
app	71.50% <ø> (+27.39%)	⬆️
g-code-testing	96.44% <ø> (ø)
protocol-designer	46.35% <ø> (ø)
shared-data	76.05% <ø> (+0.34%)	⬆️
step-generation	88.64% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...src/opentrons/protocol_engine/commands/__init__.py	100.00% <ø> (ø)
.../src/opentrons/protocol_engine/commands/command.py	94.28% <ø> (ø)
...entrons/protocol_engine/commands/command_unions.py	100.00% <ø> (ø)
...rc/opentrons/protocol_engine/execution/__init__.py	100.00% <ø> (ø)
...rons/protocol_engine/execution/command_executor.py	100.00% <ø> (ø)
...s/protocol_engine/execution/create_queue_worker.py	100.00% <ø> (ø)
...server/robot_server/commands/stateless_commands.py	100.00% <ø> (ø)

... and 829 files with indirect coverage changes

[sfoster1]

This looks good to me!