refactor(app): Drive device reset settings fully from client

[SyntaxColoring]

Overview

This refactors the desktop app and ODD components for doing a device reset.

Goes towards EXEC-1281.

Background

Historically, all of the reset options were server-defined. The client would fetch the available options from the server (via GET /settings/reset/options) and display them as-is, with server-defined text.

More recently, that model has been stretched beyond its limits:

• We want the UI to be localized with frontend-defined strings.
• We want frontend to control the options' ordering and grouping.
• We want some reset options, like onDeviceDisplay, to be special: they should be hidden from the UI and selected implicitly depending on the user's selection of other options.
• We want the server to implement some of these reset options through separate endpoints, instead of all of them through /settings/reset. (See e.g. this discussion, though I sometimes have second thoughts about this.)

So we have been in a weird in-between where we were getting the dynamic list of options from the server, but still making strong assumptions about what that list would contain. This PR rewrites it to be fully client-decided.

Changelog

This is intended to not have any user-facing change.

The one "accidental" change that I'm aware of is that if the client is newer than the server and has an extra reset option, it will now be displayed, and filtered out of the HTTP request. Formerly, it would not even be displayed.

Test Plan and Hands on Testing

• Make sure all the options are still there, with the grouping and ordering that they had before.
• Make sure the Flex-specific "select all" button still works as it did before.
• The network request is not type-safe, so test it on an actual server and make sure it succeeds.

Review requests

Specific things: see review comments below.

Also general things: React and TypeScript idioms, state structuring, and so on.

Risk assessment

Medium. This code is used for last-ditch troubleshooting and system recovery, so it needs to always work.

Possible failures include:

• Sending the wrong options if I made a typo in the mapping of UI state -> HTTP request

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 251 lines in your changes missing coverage. Please review.

Project coverage is 25.43%. Comparing base (e1eac6f) to head (7922b38).

Files with missing lines	Patch %	Lines
...edTab/AdvancedTabSlideouts/DeviceResetSlideout.tsx	0.00%	186 Missing ⚠️
...ganisms/ODD/RobotSettingsDashboard/DeviceReset.tsx	0.00%	65 Missing ⚠️

Additional details and impacted files

@@                   Coverage Diff                   @@
##           chore_release-8.4.0   #17921      +/-   ##
=======================================================
- Coverage                25.82%   25.43%   -0.39%     
=======================================================
  Files                     3005     2936      -69     
  Lines                   227433   225275    -2158     
  Branches                 18912    19272     +360     
=======================================================
- Hits                     58724    57309    -1415     
+ Misses                  168696   167953     -743     
  Partials                    13       13              

Flag	Coverage Δ
app	3.20% <0.00%> (-0.01%)	⬇️
protocol-designer	18.75% <0.00%> (-0.01%)	⬇️
step-generation	4.34% <0.00%> (-0.01%)	⬇️
system-server	?
update-server	?
usb-bridge	?

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

Files with missing lines	Coverage Δ
...ancedTab/AdvancedTabSlideouts/DeviceResetModal.tsx	0.00% <ø> (ø)
...ganisms/ODD/RobotSettingsDashboard/DeviceReset.tsx	0.00% <0.00%> (ø)
...edTab/AdvancedTabSlideouts/DeviceResetSlideout.tsx	0.00% <0.00%> (ø)

... and 69 files with indirect coverage changes

🚀 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.

[SyntaxColoring]

Disabling this button if the server options haven't been loaded yet is important to prevent this:

1. The slideout slides out
2. We try fetching the available options from the server, but it's slow
3. The user selects a bunch of checkboxes and hits the submit button
4. The request for available options from the server still hasn't returned, so serverOptions is still [], so it looks to buildResetRequest() as if all of the options are too new for the server to understand, so it filters them all out. The robot restarts, but we haven't actually reset anything.

Is there a safer, more foolproof way to deal with this?

Failing that, is there an easy way to throw in a loading indicator of some sort if this button is disabled because the server options haven't been loaded yet?

[mjhuff]

Unfortunately, no, I don't think there is an easy way of doing this given how this network request is tied to a selector in the manner that it is. I think the actual solution would be to modern the way we get this data, by placing it in a bone fide hook that wraps react-query, which calls for the settings.

Barring that, I think we could "fake" a loading state by initializing the settings to something like 'INITIALIZING', and explicitly check for the presence of that string, showing loading state as needed.

[SyntaxColoring]

We were accounting for this before by not even showing the options that were missing from the server's advertisement. Now all of the options are always shown, so we need to filter them here.

[mjhuff]

Looks great, thanks! Nice and clean. If you're keen on adding explict loading state in this PR, we could do so, but I don't think it's necessary for merging.

[TamarZanzouri]

YOU DID IT!!!! nice job Max!