[teleport-update] Add support for reloading the agent & reverting symlinks on failed reload

[sclevine]

This PR adds support for reloading the Teleport agent process when the enable subcommand to the teleport-update binary is executed. Additionally, this PR reverts the system to the previously installed version of the agent on failure.

This PR also adds:

• Additional validation when creating symlinks so that they cannot replace regular files (e.g., real Teleport binaries)
• Fixes to symlink directory permissions (0750 -> 0755)
• Ungraceful restart fallback when graceful reloading fails

Notably, this PR is missing:

• Proper healthchecking for the Teleport service (see TODO)

This is the fourth in a series of PRs implementing teleport-update:
Linking: #47879
Enable Command: #47565
Initial scaffolding PR: #46418

The teleport-update binary will be used to enable, disable, and trigger automatic Teleport agent updates. The new auto-updates system manages a local installation of the cluster-specified version of Teleport stored in /var/lib/teleport/versions.

RFD: #47126
Goal (internal): https://github.com/gravitational/cloud/issues/10289

---

Example:

ubuntu@legendary-mite:~/mounts/teleport/tool/teleport-update$ sudo ./teleport-update enable --proxy=levine.teleport.sh --force-version=16.4.3
2024-10-28T21:25:23Z INFO [UPDATER]   Version already present. version:16.4.3 agent/installer.go:145
2024-10-28T21:25:23Z INFO [UPDATER]   Target version successfully installed. version:16.4.3 agent/updater.go:334
2024-10-28T21:25:23Z INFO [UPDATER]   Teleport gracefully reloaded. agent/process.go:75
2024-10-28T21:25:23Z INFO [UPDATER]   Backup version set. version:16.4.2 agent/updater.go:356
2024-10-28T21:25:23Z INFO [UPDATER]   Configuration updated. agent/updater.go:375
ubuntu@legendary-mite:~/mounts/teleport/tool/teleport-update$ ls -la /usr/local/bin
total 8
drwxr-xr-x  2 root root 4096 Oct 28 21:27 .
drwxr-xr-x 10 root root 4096 Oct  8 23:12 ..
lrwxrwxrwx  1 root root   53 Oct 28 21:27 fdpass-teleport -> /var/lib/teleport/versions/16.4.3/bin/fdpass-teleport
lrwxrwxrwx  1 root root   42 Oct 28 21:27 tbot -> /var/lib/teleport/versions/16.4.3/bin/tbot
lrwxrwxrwx  1 root root   42 Oct 28 21:27 tctl -> /var/lib/teleport/versions/16.4.3/bin/tctl
lrwxrwxrwx  1 root root   46 Oct 28 21:27 teleport -> /var/lib/teleport/versions/16.4.3/bin/teleport
lrwxrwxrwx  1 root root   41 Oct 28 21:27 tsh -> /var/lib/teleport/versions/16.4.3/bin/tsh
ubuntu@legendary-mite:~/mounts/teleport/tool/teleport-update$ ls -la /usr/local/lib/systemd/system/
total 12
drwxr-xr-x 2 root root 4096 Oct 28 21:27 .
drwxr-xr-x 3 root root 4096 Oct 28 19:03 ..
lrwxrwxrwx 1 root root   62 Oct 28 21:27 teleport.service -> /var/lib/teleport/versions/16.4.3/etc/systemd/teleport.service
ubuntu@legendary-mite:~/mounts/teleport/tool/teleport-update$ cat /var/lib/teleport/versions/update.yaml 
version: v1
kind: update_config
spec:
    proxy: levine.teleport.sh
    group: ""
    url_template: ""
    enabled: true
status:
    active_version: 16.4.3
    backup_version: 16.4.2

[vapopov]

nit: btw Teleport has indirect dependency of https://github.com/coreos/go-systemd which we might use https://github.com/coreos/go-systemd/blob/main/dbus/methods_test.go#L205
I don't say that is better, just suggestion

[sclevine]

Thanks for pointing this out. I lean towards using systemctl for now, since it's guaranteed to be present in the context the agent is executing on a machine with systemd, and we're likely going to port the existing updater logic for now. We can revisit later.