Data & Fixture Migrations v005

[ErisDS]

This is a brand new PR for pushing migrations that need to happen in 005 📚 🚀

Back in #6302, we had migrations that were auto-calculated from the schema / fixtures files. This was easier to do at face value, but felt risky because it was impossible to test and verify that changes would work correctly. The new version requires us to write more code, but gives us more guarantee that the upgrades will work now and in the future.

From here on, each change to the schema or fixtures needs to follow some rules:

• changes to schema or fixtures must be accompanied by a matching upgrade task
• all upgrades should have a check to ensure that they only run if they are needed
• all migration code should have 100% unit test coverage

[ErisDS]

@sebgie in the last migration here, I've added a new ghost-scheduler client, which is intended to be used for calling back to the scheduling API #6399 at the correct time. This client, unlike the existing two, is going to be confidential rather than public, I believe?
To indicate this, I've given it a type of wa rather than ua. This comes from the spec here, which is the only reference I could find to a ua type. Is this what you expected? Is it worth us adding an isIn validation to type in the schema to enumerate the allowed values?

[sebgie]

Is this what you expected?

Yes, the types are meant to reflect the specification. Tbf, na for native application could look like not available?

name	short
user-agent	ua
web application	wa
native application	na

[ErisDS]

Fair point, I was just following along from what was there, I don't think there's a particular reason to keep them so short - ua makes sense for user agent, but we could make the other two clearer?

name	short
user-agent	ua
web application	web
native application	native