docs(robot-server): Update GET /health response examples

[SyntaxColoring]

Overview

The HTTP API docs were showing an incomplete example for GET /health. (@y3rsh thanks for catching this.)

Test Plan

Run make -C robot-server dev and view https://localhost:31950/redoc#tag/Health/operation/get_health_health_get.

Changelog

• Fix some fields, especially robot_type, not being shown in our GET /health example response on ReDoc. Before, after.
  • ReDoc normally keeps this stuff up to date automatically. The problem was that our Python code overrode the examples for the whole model instead of just for specific fields. This changes it to only override the examples for specific fields, so unmentioned fields will have their examples autogenerated, like we want.
• Update the example values for name and robot_serial to show how they can be different. Otherwise, leave the existing example values in place.

Review requests

• Are there any apparent downsides to defining the examples field-by-field like this?
• There are a lot of other old endpoints that theoretically have this same problem. Searching robot-server for schema_extra is a good starting point. Do we want to ticket that, or just let it lie?

Risk assessment

Low.

[ecormany]

Tested in the sandbox for this branch. Generally looks good, although I see this in the links entry at the bottom of the example:

  "links": {
    "apiLog": "/logs/api.log",
    "serialLog": "/logs/serial.log",
    "serverLog": "string",
    "oddLog": "string",
    "apiSpec": "/openapi.json",
    "systemTime": "/system/time"
  }

1. Should there be an actual value for serverLog?
2. Should oddLog be hidden or have a null value because this example is for an OT-2?

[SyntaxColoring]

Should there be an actual value for serverLog?

Yes, thank you. Fixed for serverLog and oddLog.

Should oddLog be hidden or have a null value because this example is for an OT-2?

Yeahhh maybe. A downside of doing field-level examples like this is that the example sort of becomes an amalgamation. I think that's okay-ish in principle because it demonstrates all the fields that could exist, even if they won't necessarily exist together, but I acknowledge it's potentially confusing.

I'm going to leave it non-null for now.

[ecormany]

Looks good with the new additions.

We can clear up the oddLog on OT-2 confusion later with either:

• better documentation
• rational behavior if you try to query the file at that path (valid blank file or a simple JSON object that says "OT-2 doesn't have a touchscreen" or what have you)