fix: apply k3s version bumps declaratively through site.yml

[lexfrei]

What

Re-running site.yml with a raised k3s_version now upgrades the running cluster instead of only replacing the on-disk binary. Previously the install script replaced the binary but never restarted the service (INSTALL_K3S_SKIP_START), and the roles only restarted on a config change — so a version-only bump left agents and joined servers running the old runtime until they were restarted by hand.

Why

This makes site.yml safely declarative for the cluster lifecycle, which is the ask in #485. It rebuilds the direction started in #505 on top of the now template-free roles: that earlier PR was parked pending the jinja-to-config.yaml refactor, which has since landed, so this is a fresh implementation rather than a rebase of it.

How

• The server and agent roles track whether the k3s binary was actually replaced and restart when it was, in addition to the existing config-change trigger.
• The server play runs with serial: 1 (matching upgrade.yml) and each restarted server — including the first — waits for its API to report healthy before the play moves on, so a rolling change never drops the etcd quorum.
• The joined-server readiness check waits for the servers handled so far rather than the full set, which keeps it correct under both serial and parallel runs.
• Integration tests upgrade through site.yml (single server + agent, and the three-server HA path) and assert the running version the kubelet reports, not the on-disk binary, so the tests fail if the restart ever regresses.

Scope note

upgrade.yml and the k3s_upgrade role are intentionally left in place and unchanged. #485 also suggested removing them, but that is a larger, breaking change (a v2.0.0 concern) and is deliberately out of scope here — site.yml simply gains the declarative-upgrade capability alongside the existing playbook.

Testing

The full integration suite — including the HA job's rolling site.yml version bump across three etcd servers — was run green on a fork before opening this PR.

Addresses #485. Builds on the approach in #505 (credited via Co-authored-by on the commit).

[dereknola]

We still want to test the older upgrade playbook. People are still using it. Keep this here and test the second upgrade with the site.yml

[lexfrei]

Restored the upgrade.yml test and added the site.yml bump as a second upgrade on top of it (start → upgrade.yml → site.yml, across three real k3s versions). The HA job already ran them in that order.

[dereknola]

Lets just simplify this and always make it restarted because that's guaranteed to bounce the service and handle both cases, then we don't need to do a bunch of logic around determining if the binary was replaced.

[lexfrei]

Simplified to always state: restarted and dropped the binary-change detection. Applied the same simplification to the server role for consistency: the first server already always restarted, and joined servers now do too — still one at a time behind serial: 1 + the health check, so the etcd quorum is preserved.

[dereknola]

We are not going to reduce the initial install of k3s to serial just to support upgrades. If you want this, use the ansible-playbook site.yml --forks=1 system to force serial. Include that in the documentation.

[lexfrei]

Done — dropped serial: 1 from the server play, so a fresh install runs in parallel as before. The joined-server restart is now unconditional, which is the actual version-bump fix (the first server and the agents already always restart). The README documents running a multi-server upgrade with --forks=1, and the HA integration test now runs the site.yml upgrade with --forks=1 so that path is covered.