feat(robot-server): Return a currentlyRecoveringFrom command pointer

[SyntaxColoring]

Overview

Goes towards EXEC-458.

Test plan

I'm unable to push this to a robot because of problems that appear unrelated (ModuleNotFoundError: No module named 'usb'). I think this is low-risk enough that we can get away with skipping it.

Changelog

This adds a currentlyRecoveringFrom command pointer to GET /runs and GET /maintenance_runs, adjacent to current, and wires it up to the underlying ProtocolEngine.

This does not yet send MQTT notifications for it, nor does it update the frontend code to take advantage of the new pointer. Doing those in follow-up PRs.

Review requests

API design. Is this helpful to the client? Does it have simple and maintainable semantics? The term "current command" has historically been the subject of much confusion, and I wouldn't want the same thing to happen here. Would it be better or worse to define this more literally, like mostRecentFailedProtocolCommand?

Risk assessment

Low.

[sfoster1]

I think that “recovery target” is kind of a misleading name for this, because you might not actually be recovering from the command that gets pointed to there - it might not be recoverable, for instance, or it might already have been recovered from: if command C fails, is recovered, and the protocol succeeds, command C will continue to be the thing that gets returned.

I think this should be “lastFailedProtocolCommand” or something specific like that.

[SyntaxColoring]

I think that “recovery target” is kind of a misleading name for this, because you might not actually be recovering from the command that gets pointed to there - it might not be recoverable, for instance, or it might already have been recovered from: if command C fails, is recovered, and the protocol succeeds, command C will continue to be the thing that gets returned.

I think this should be “lastFailedProtocolCommand” or something specific like that.

I spoke with @mjhuff about this, and it turns out we do not actually want command C to continue to be the thing that gets returned in this case. It's easier for the client if the return value goes back to being null after a command is recovered from.

[mjhuff]

This makes sense to me. As discussed in person, we might think about extending this to other routes in the future, but /commands is as much as we need right now. Thank you for implementing this!

EDIT: I can help test tomorrow if you'd like, but code LGTM.