Migration miscount when migration numbers are missing

[placer14]

FYI, I think I discovered a bug in the migration handling. Scenario:
Migrations in the build are 1-6 and 8 (due to testing merges which coincidentally missing the 7th migration).
I migrated from 6 -> 8 using --to 8
I ran tests. Then tried to migrate with --to 6 which logged the following:

ubuntu@comp0-large:~/sentinel/visor$ ./visor --tracing=false --log-level=info migrate --to 6
2020-10-10T20:50:01.680Z        INFO    storage storage/migrate.go:110  current database schema is version 8
2020-10-10T20:50:01.680Z        WARN    storage storage/migrate.go:136  running destructive schema migration from version 8 to version 7
2020-10-10T20:50:01.749Z        INFO    storage storage/migrate.go:142  current database schema is now version 7
2020-10-10T20:50:01.749Z        WARN    storage storage/migrate.go:136  running destructive schema migration from version 7 to version 6
2020-10-10T20:50:01.927Z        INFO    storage storage/migrate.go:142  current database schema is now version 5

DB state is definitely at 5 and not at 6 with migration table looking like:

11	8	2020-10-09 22:02:56.77737+00
12	7	2020-10-10 20:50:01.693026+00
13	5	2020-10-10 20:50:01.749649+00

[placer14]

Looking at the logic around this, it seems that there's no association with number to migration and the system just assumes every step backward is a single step. Not obvious how we can make sure this doesn't bite us again without having a map of specific migrations to numbers and doing some comparison before blindly executing the down a number of steps between current and --to.