v0.4.1 / v0.5.0 repo pivot migration

[tjkirch]

#905 (comment)

v0.4.0 added support for signed migrations (#930) and v0.5.0 will remove support for unsigned migrations. To make sure this doesn't break customers upgrading from older versions when we no longer produce unsigned migrations, v0.4.0 will be a "pivot" version.

A "pivot" version means that we'll stop using the current repo prefix ("2020-02-02") we'll move to a new repo prefix (TBD). The migration to v0.5.0 will change the repo URL. v0.5.0 will be the last version in the old prefix. The effect is that users will move through this version before getting new updates, and so we only have to produce signed migrations from then on. (v0.4.0 will be the first version in the new prefix; this will allow downgrading to the old repo prefix through the same process in reverse.)

The downside is that it will require an extra reboot in the case that a user doesn't update for a while -- if they sit on v0.4.0 until v0.6.0 is released, they still have to go through v0.5.0, unlike our normal continuous update stream. The benefits are (1) security, (2) backwards compatibility, meaning it's still possible to upgrade/downgrade, whereas alternate approaches are breaking updates, and (3) it gives us practice doing major changes to the upgrade system itself.

This issue covers creating the migration that changes repo URLs, and thinking through any consequences we may have to solve for v0.5.0 release.

[tjkirch]

Upgrade workflow: an instance will see v0.5.0 in the existing 2020-02-02 repo -- nothing newer will be available. It will include a migration that changes the repo URL. The instance updates to v0.5.0 and starts seeing updates from the new repo, which will be initialized with v0.4.0 and v0.5.0, including the same migration for that transition.

Downgrade workflow: an instance can choose to downgrade to v0.4.0 in the new repo -- nothing older will be available. The migration for v0.5.0 -> v0.4.0 will update the repo URL to the old 2020-02-02 repo. After update, the instance will see updates for v0.5.0 and earlier, and can further downgrade if desired, or upgrade back to v0.5.0 to move back to the new repo.

[tjkirch]

My plan above wouldn't work. We need versions before 0.4 in the current repo to be able to upgrade to 0.5, so we can't remove the unsigned migration compatibility code until we're in the new repo where we know all versions understand signed migrations.

So, the work we planned for "0.5" will actually be in "0.4.1", and v0.5 will be the next release, and include the removal of the compatibility code. The old repo will go up through 0.4.1, and the new repo will include 0.4.0 onwards. (0.4.0 so you can downgrade back to the old repo.)

See #971 for bringing compat back temporarily; I'll rename the 0.5 milestone to 0.4.1, and add an issue to a new 0.5 milestone to remove it again.