fix(api): fix APIv1 GPIO ctl for cmdline and jupyter protocol execution

[ahiuchingau]

Overview

When the robot server is running, protocols executed in Jupyter or using opentrons_execute would not have control over the GPIOs. Currently, a warning with a workaround is shown if the protocol is in APIv2. However, there is no indication given to the user of why GPIO controls are not working when they are running a v1 protocol.

This PR fixes the issue by surfacing the same warning as v2 and actually implementing the workaround for v1 protocols.

closes #6045

Changelog

• adds a new info message right before GPIO chardev is being built in APIv1
• allowed GPIO chip access during robot.connect

  • this automatically surfaces the following warning when a v1 protocol is executed in Jupyter or via opentrons_execute:
    Failed to initialize character device, will not be able to control gpios (lights, button, smoothie kill, smoothie reset). If you need to control gpios, first stop the robot server with systemctl stop opentrons-robot-server. Until you restart the server with systemctl start opentrons-robot-server, you will be unable to control the robot using the Opentrons app.

  • if the GPIOs are not held by the robot server, the resulting GPIOCharDev (not the simulator) will be set as the robot._driver.gpio_chardev

• added setup_v1 function in gpio.py so robot can setup GPIO pins without being async

Review requests

Not sure if adding GPIOCharDev.setup_v1 is the best way to tackle the problem, any suggestions?

Test this PR by executing robot.turn_on_rail_lights() in Jupyter and using opentrons_execute:

1. before killing the robot server, a warning should be shown that the GPIO char dev has failed to initialized
2. after killing the server, no warning and the robot lights should turn on

Risk assessment

Low - this PR only affects APIv1 protocols when the robot server is stopped

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (edge@987ae85). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             edge    #6091   +/-   ##
=======================================
  Coverage        ?   79.18%           
=======================================
  Files           ?      187           
  Lines           ?    18144           
  Branches        ?        0           
=======================================
  Hits            ?    14367           
  Misses          ?     3777           
  Partials        ?        0           

Impacted Files	Coverage Δ
opentrons/helpers/helpers.py	87.33% <0.00%> (ø)
opentrons/protocol_api/constants.py	100.00% <0.00%> (ø)
opentrons/legacy_api/modules/__init__.py	80.76% <0.00%> (ø)
update-server/otupdate/buildroot/__init__.py	85.29% <0.00%> (ø)
...ice/session/command_execution/hardware_executor.py	97.05% <0.00%> (ø)
opentrons/hardware_control/socket_server.py	87.57% <0.00%> (ø)
...erver/robot_server/service/legacy/rpc/serialize.py	97.14% <0.00%> (ø)
...server/robot_server/service/legacy/routers/logs.py	100.00% <0.00%> (ø)
...r/robot_server/robot/calibration/helper_classes.py	80.00% <0.00%> (ø)
...er/robot_server/service/legacy/routers/settings.py	100.00% <0.00%> (ø)
... and 177 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 987ae85...8651472. Read the comment docs.

[sfoster1]

Nice, looks like a good workaround

[SyntaxColoring]

Can we hold off on merging this, for a sec? I'll start a discussion in Slack.