Default AnyLink implementation

[dnsl48]

Summary

In support for the RFC-30 we need to come up with a robust default AnyLink implementation.

That link type is expected to be used the most and should be able to represent other link types (depending on the CMS user choice).

Acceptance Criteria

• Should be following the RFC-30 Option C data model description (DBComposite)
• Should provide a "pool" of available "common" database fields, so most link type implementations reuse the same fields and only introduce "extra" DB fields in edge cases
• Should not require extra manual configuration when adding link types to an application
• Supports modifying the behaviour of built-in link types without needing to modify existing database records, through modules or project-specific customisations. Example: An existing website owner wants to allow optional email subjects on their email links. After customising the existing "email" link (form field, data model), the functionality is available on both existing and new database records
• Supports ~10 link fields on a given record without running into limitations on supported databases, while minimising the performance impact on related subsystems (e.g. querying, versioned tracking, dev/build, GraphQL schema building)
• There is test coverage for this implementation (scaffolding will be covered in another issue)

[chillu]

I've got a few more ;)

• Supports modifying the behaviour of built-in link types without needing to modify existing database records, through modules or project-specific customisations. Example: An existing website owner wants to allow optional email subjects on their email links. After customising the existing "email" link (form field, data model), the functionality is available on both existing and new database records
• Supports ~10 link fields on a given record without running into limitations on supported databases, while minimising the performance impact on related subsystems (e.g. querying, versioned tracking, dev/build, GraphQL schema building)

[maxime-rainville]

Sounds good. On the graphQL bit, it's worth pointing out that DBFile currently has it's own special grahpql type. https://github.com/silverstripe/silverstripe-graphql/blob/3/_config/assets.yml

We'll probably need some similar logic for this, but that's probably a problem for another card.

[chillu]

Just to clarify: With "Supports 10 link fields" I mean 10 entries in static $db. We'll build in 4 link types (internal page, external URL, email, file), and a handful of projects might have one or two additional ones (e.g. phone number, document management system integration, etc). It's very unlikely that any Silverstripe project will have 10 link types.