Streamline migration from v2/v3 to v4

[maxime-rainville]

As a developer maintaining a project using LinkField v2/v3, I have a a clear path and clear guidance on how to migrate to v4.

Acceptance criteria

• A BuildTask exists to converts LinkField v2/v3 data to v4 format.
  • The task accounts for versioning and all pre-existing links are assumed to be published.
  • Task accounts for HasMany relations to Link
  • Task can be extended to accommodate unusual usage of LinkField.
• Deprecation warnings are added to v3. see Add deprecation warnings to v3 #246
• Clear guidance on how to migrate to v4 is provided
• Guidance covers the scenario where a project is upgraded all the way from CMS 4.
• Guidance covers how to migrate custom link types.
• Guidance mentions that we are assuming no versioning of v2/v3 links
• Migration task is marked as @deprecated.
• The task is disabled by default.

Exclude

• Migration of DBLink data.

Possible unusual v3 customisations

• Versioned links in V3
• Custom links types
• Link data with Fluent

PRs

See this installer run for green CI with the combined PRs.

• Enhancements required for linkfield migration silverstripe-framework#11171
• NEW Add migration task from older versions of the module #244
• DOC Add changelog note about SQLUpdate supporting JOIN developer-docs#481

[GuySartorelli]

Should the task be enabled or disabled by default?
I'd recommend disabled by default so it's not present for new installations. Developers who are migrating can enable it with a simple yaml config, run it, and disable it again afterward.

Bear in mind this is one of three migration tasks, and only one of these will apply to any given project, so probably makes sense to not show them all by default.

[maxime-rainville]

My assumption was be that this task would a dev/build task. You would have to explicitly choose to run the task by calling it. This would seem to negate the need to have the option to enable/disable it.

Did you have something else in mind?