[rubenvdlinde]

Part of #3099, on top of #3131 (data model). This adds the behaviour #3100 describes for widgets, still without an API or UI.

Size: 1717 lines: 627 code, 1090 tests.

• Saving a page replaces its widgets in one transaction, matched by id. Existing widgets are updated, new ones added, and missing ones removed.
• Deleting a page or an application deletes its widgets and their sources.
• Removing a table or view from an application deletes only the source rows that point at it, first and in the same transaction as the rest. The widget stays, and later shows that it needs a new table.
• Moving a user's data (TablesMigrator) carries an application's pages, widgets and settings. A widget source only comes along when it points at the table being imported: importContext() maps every node to that table, so a source for another table would land on the wrong one. Imported widgets and page texts are checked the same way as saved ones, and invalid ones are skipped with a warning in the log.
• Exporting and importing an application's scheme doesn't carry pages and widgets yet. We'd like to add that in a follow-up pull request.
• Widget types (header, text, table or view) are defined in one place on the server, each with the schema its settings are checked against. Colours must be #rgb or #rrggbb.
• Limits: at most 100 widgets per page and 60,000 bytes of settings per widget (under MySQL's 64 KB for TEXT). An import skips what goes over.
• A widget's source must be a table or view of the page's own application. The service checks this itself, not only the API.

Data exported with widgets can't be imported into an older version of Tables. That belongs in the changelog.

Three smaller changes come with it:

• Context responses now carry each page's title, icon, description and technical name.
• A grid page no longer gets an empty entry in the start page list.
• Importing skips a start page entry whose table didn't come along. Before, it wrote an empty value into a column that doesn't allow one.

The widget types aren't in ResponseDefinitions yet, because the OpenAPI generator refuses schemas that no endpoint uses. They move there together with the endpoints in the next pull request.

Why nothing breaks

There is still no way to create a widget, so all of this runs on empty tables. Deleting an application or removing a table behaves as before; it now also checks two more tables.

How it was tested

On Nextcloud 34 with PostgreSQL:

• WidgetServiceTest (database, including clearing a widget title back to empty, and refusing a widget id from another page)
• GridWidgetTypesTest and ContextServiceTest
• ContextPagesRoundTripTest (database: export, import, removing a table, deleting an application)
• ContextMapperTest and TablesMigratorTest
• a broken export file and a two-table user migration
• the full unit suite on the top of the stack (feat(contexts): carry the menu through export and import #3138), on PostgreSQL and SQLite: 665 tests
• composer cs:check, psalm and rector, all clean

🖼️ Screenshots

Backend only, no UI changes.

🏁 Checklist

• ⛑️ Tests (unit and/or integration) are included or not needed
• 🔙 Backport requests are created or not needed: /backport to stableX.X
• 📅 Milestone is set
• 🌸 PR title is meaningful (if it should be in the changelog: is it meaningful to users?)

🤖 AI (if applicable)

• The content of this PR was partly or fully generated using AI