fix(api, shared-data, robot-server): stringify all error info in run log

[fsinapi]

Overview

The GET /runs endpoint was returning a 500 error in some cases as a result of invalid entries in the robot run log. In the specific case of RQA-1872, the cause is a non-string entry in the errorInfo dictionary for an error that failed a run. To get more specific, the issue was that the PipetteOverpressureError exception was being created with an info field with a value field that was an instance of OT3Mount.

Before this PR, our enumerated errors would accept a dictionary with string keys and any value type. This PR changes the classes to force the dictionary values to be strings. The ErrorOccurrence constructor was not performing any validation on its inputs because it was using the construct method, and now it doesn't have to worry about that because any exceptions have to use strings.

In addition, this PR adds a catch for ValidationErrors when getting the State Summary from the Run Store. It will return None, which is already tolerated by the higher calling functions in the GET /runs chain.

Test Plan

Fail a run with an overpressure error on a robot with current edge, then push this branch, and then make sure GET /runs doesn't return a 500 error (there should be an empty state summary for the run that failed).

Changelog

Review requests

Risk assessment

Pretty low, touches error handling that was already broken and stringifies a bunch of error messages.

[codecov]

Codecov Report

Merging #13942 (2732439) into edge (d826bfb) will decrease coverage by 0.12%.
Report is 1 commits behind head on edge.
The diff coverage is n/a.

Additional details and impacted files

@@            Coverage Diff             @@
##             edge   #13942      +/-   ##
==========================================
- Coverage   70.66%   70.55%   -0.12%     
==========================================
  Files        2508     1631     -877     
  Lines       70726    54259   -16467     
  Branches     8681     3854    -4827     
==========================================
- Hits        49977    38281   -11696     
+ Misses      18626    15304    -3322     
+ Partials     2123      674    -1449     

Flag	Coverage Δ
app	38.69% <ø> (-29.39%)	⬇️
g-code-testing	96.44% <ø> (ø)
notify-server	89.13% <ø> (ø)
protocol-designer	45.63% <ø> (ø)
shared-data	73.04% <ø> (ø)
step-generation	84.95% <ø> (ø)

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

Files	Coverage Δ
api/src/opentrons/hardware_control/api.py	82.42% <ø> (ø)
...entrons/hardware_control/backends/ot3controller.py	67.85% <ø> (ø)
api/src/opentrons/hardware_control/ot3api.py	79.41% <ø> (ø)
.../src/opentrons/protocol_runner/json_file_reader.py	100.00% <ø> (ø)
robot-server/robot_server/runs/run_store.py	100.00% <ø> (ø)
.../python/opentrons_shared_data/errors/exceptions.py	60.59% <ø> (ø)

... and 880 files with indirect coverage changes

[sfoster1]

Perfect, thanks! Let's log in that except tho

[sfoster1]

Awesome, thanks!

[fsinapi]

Tested on Flexington. Confirmed that the route no longer returns an error, and the app is able to get past the initializing screen. The summary of the run is misleading since it returns a fake empty state summary, we should be sure to follow up on that.