migrations: migration to add 'version-lock' & 'ignore-waves' settings

[etungsten]

Issue number:
N/A

Description of changes:

Author: Erikson Tung <etung@amazon.com>
Date:   Mon Jun 29 12:01:27 2020 -0700

    migrations: migration to add 'version-lock' & 'ignore-waves' settings
    
    Adds a migration for adding two new update settings: 'version-lock' and
    'ignore-waves'

Testing done:
Basically the same testing done in #958

The source datastore has the following content for update settings:

$ ls -al ds/current/live/settings/updates
total 32
drwxr-xr-x 2 etung domain^users 4096 Jun 25 14:05 .
drwxr-xr-x 6 etung domain^users 4096 Jun 25 14:05 ..
-rw-r--r-- 1 etung domain^users    5 Jun 25 14:05 ignore-waves
-rw-r--r-- 1 etung domain^users   46 Jun 25 14:01 metadata-base-url.setting-generator
-rw-r--r-- 1 etung domain^users   80 Jun 25 14:01 metadata-base-url.template
-rw-r--r-- 1 etung domain^users   11 Jun 25 14:01 seed.setting-generator
-rw-r--r-- 1 etung domain^users   43 Jun 25 14:05 targets-base-url
-rw-r--r-- 1 etung domain^users    8 Jun 25 14:05 version-lock

Forward migration:

     Running `add-version-lock-ignore-waves --source-datastore ~/thar/testing/ds/current --target-datastore ~/thar/testing/ds/next --forward`
AddSettingsMigration(["settings.updates.version-lock", "settings.updates.version-lock"]) has no work to do on upgrade.

Observed that the temporary datastore created matches the source datastore, which is expected.

Backwards migration:

     Running `add-version-lock-ignore-waves --source-datastore ~/thar/testing/ds/current --target-datastore ~/thar/testing/ds/next --backward`
Removed settings.updates.version-lock, which was set to '"latest"'
Removed settings.updates.ignore-waves, which was set to 'false'

Observed that the temporary datastore no longer has the version-lock and ignore-waves settings.

$ ls -al ds/next/live/settings/updates
total 24
drwxr-xr-x 2 etung domain^users 4096 Jun 29 11:50 .
drwxr-xr-x 6 etung domain^users 4096 Jun 29 11:50 ..
-rw-r--r-- 1 etung domain^users   46 Jun 29 11:50 metadata-base-url.setting-generator
-rw-r--r-- 1 etung domain^users   80 Jun 29 11:50 metadata-base-url.template
-rw-r--r-- 1 etung domain^users   11 Jun 29 11:50 seed.setting-generator
-rw-r--r-- 1 etung domain^users   43 Jun 29 11:50 targets-base-url

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[webern]

Should we add migrations to Release.toml when they are created, or later?

[etungsten]

Should we add migrations to Release.toml when they are created, or later?

Later. When we cut the next release, the migration would then need to be added to Release.toml.