Don't save migrated startup-config #1637

Problem

On upgrade, Infix migrates startup-config to the new syntax and writes the result back to disk immediately. If confd then fails to parse the migrated file — or the upgrade fails for any other reaso, the system falls back to failure-config.

If the user can't log in to troubleshoot from fail-safe mode, the natural recovery path is to reboot into the secondary A/B partition, which runs the previous (working) Infix version. But by then startup-config has already been overwritten with the migrated syntax. The old confd can't parse it either, so the secondary boot also falls back to failure-config.

Net effect: a failed migration can strand the user with no working config on either partition, even though the actual config that worked pre-upgrade still logically exists — it's just been clobbered.

Proposal

Don't persist the migrated config to startup-config as part of the upgrade path. Migrate in memory / into the running config only. Leave the on-disk startup-config in its original (old) syntax until the user explicitly commits:

copy running-config startup-config

This makes the A/B fallback safe again: the secondary partition always finds a startup-config it can parse, because migration never touched disk. The user is expected to log in post-upgrade, verify the running config, and save it themselves once satisfied.

Open questions

Do we want any signal/alarm that running != startup post-migration, beyond CLI/banner?

Independent of the above, once an upgrade is confirmed successful, the user should be prompted/reminded to also upgrade the secondary (now-inactive) partition. Otherwise the secondary keeps running an old Infix version indefinitely, and a future fallback to it lands on stale software as well as stale config. Worth deciding whether this is a CLI hint, a login banner, or something more automatic even?

Trade-offs

• Adds a manual step post-upgrade: startup-config stays on old syntax until the user runs copy running-config startup-config themselves — either right after upgrade, or implicitly the next time they save any config change. This is not a problem for unattended/zero-touch upgrades: confd already detects a stale infix-meta:version in startup-config at every boot and re-migrates into running config regardless, so the system keeps working across reboots even if the file on disk is never updated.
• Alternative considered: keep saving the migrated file, but only after confirming confd can parse it back (round-trip validate before commit to disk), combined with keeping a .pre-migration backup of the old file for manual recovery. More automatic, but more complex, and still doesn't close the A/B gap — the old-version confd on the secondary can't read the new syntax regardless of how well the new-version confd validated it.
• We should decide whether to solve this in general (any config migration) or scope it strictly to the startup→new-syntax upgrade migration case.