bug: GET /health and GET /server/health disagree on the robot's name

[SyntaxColoring]

Overview

From @mcous:

I’ve noticed at least that after a rename, GET /health and GET /server/update/health don’t seem to agree on the name... [Discovery Client] defers to the update-server in this case, which is correct, but seems dicey

Steps to reproduce

1. Change a robot's name via POST /server/name {"name": "new name"}.
2. Quickly compare the POST response, the response to GET /health, and the response to GET /server/update/health.

Current behavior

I think POST /server/name and GET /server/update/health are correct, but GET /health lags behind and shows the old name.

Output from cd discovery-client && yarn run discovery after changing the name from OLDNAME to NEWNAME:

{
  name: 'NEWNAME',
  health: {
    name: 'OLDNAME',
    robot_model: 'OT-2 Standard',
    api_version: '6.0.0',
    fw_version: 'v1.1.0-25e5cea',
    board_revision: '2.1',
    logs: [
      '/logs/serial.log',
      '/logs/api.log',
      '/logs/server.log',
      [length]: 3
    ],
    system_version: 'v1.10.0',
    maximum_protocol_api_version: [ 2, 12, [length]: 2 ],
    minimum_protocol_api_version: [ 2, 0, [length]: 2 ],
    links: {
      apiLog: '/logs/api.log',
      serialLog: '/logs/serial.log',
      serverLog: '/logs/server.log',
      apiSpec: '/openapi.json',
      systemTime: '/system/time'
    }
  },
  serverHealth: {
    updateServerVersion: '6.0.0',
    apiServerVersion: '6.0.0',
    smoothieVersion: 'unimplemented',
    systemVersion: 'v1.10.0',
    capabilities: {
      buildrootUpdate: '/server/update/begin',
      restart: '/server/restart'
    },
    name: 'NEWNAME',
    serialNumber: 'bitter-wood',
    bootId: 'f723c623-b8dc-41c2-936a-43cca75c0c31'
  },
  addresses: [
    {
      ip: '192.168.86.233',
      port: 31950,
      seen: true,
      healthStatus: 'ok',
      serverHealthStatus: 'ok',
      healthError: null,
      serverHealthError: null
    },
    [length]: 1
  ]
}

Expected behavior

GET /health and GET /server/health should probably always agree on the name.

All of the name fields printed by yarn run discovery should eventually agree.

[SyntaxColoring]

Possibly relevant:

https://www.freedesktop.org/wiki/Software/systemd/hostnamed/

Note that hostnamed starts only on request and terminates after a short idle period. This effectively means that PropertyChanged messages are not sent out for changes made directly on the files (as in: administrator edits the files with vi). This is actually intended behavior: manual configuration changes should require manual reloading of them.

And update-server does make changes directly on the files, currently.

We could either:

• Have update-server restart/reload systemd-hostnamed after a rename
• Have update-server implement the rename through in a way other than by directly writing to files. See: fix(update-server): Avoid bricking when given a bad name #10219 (comment)