Harden Repairsteps and migration

[dartcafe]

First I was trying to force reloading of changed types and to ensure that outdated classes are not used anymore. The Idea was to define an alias for the Classes used while updating

Long story short; This ended in a crucial refactoring with a lot of side effects and a massive grown complexity.

Backt to the long story:
The background is, polls uses another declarative way in migrating and creating database structures. The recommended way is to add a new migration, once the database has to be touched. Over the years this would have become unmaintainable IMHO.

Polls uses a declarative way to define tables, their relations and indices and constraints. The value is a centralized definition of the database and the possibilty to have commands like polls:db:rebuild without massive code duplication, which help to create a consistent database schema, nevertheless what has changed inside the database, if you removed indices, deleted a table, and so on. ... and more convenient, if the database has to be changed, sind only properties have to be changed or added to the table definition.

The downside is an effect, that while updating, Nextcloud can't load changed classes, because when the code is replaced during the update process, the old class may be probably already loaded - with it's old signature. This causes Exceptions, if the Table and Index definitions or Manager methods got changed.

Also Polls makes heavy usage of the repair steps, to ensure some checks and fixes are executed on every install|update|enabling.

So the decision was made to change this completely.

• The definitions are now versioned, so that if methods change, are added, etc. a new version of the definition will be force loaded (i hope the strategy works, taking these words for real: [Bug]: When running repair steps for the first time, changed classes get not loaded properly server#38158 (comment)).
• Polls will just know exactly one migration
• All repair steps got moved to the preSchemaChange and postSchemaChange methods of the migration.

What is the desired Value:

• pre- and post-migration actions are now only executed, if a new migration exists, speeding up code-only updates
• Changed classes (tableSchema and Managers) should always be loaded in their current incarnation as they get versioned and appear as new class
• Still identical actions for migrations and occ commands
• Fixing the following issues:

fixes #4206
fixes #4213
fixes #4210
fixes #4206 (to be honest, was fixed in another PR)

If anyone followed until here: Hello 👋

After simulating millions of installs, updates, dis- and enabling, destroying and repairing the db , I would like to rely on some guys who can give feedback, if any issues still exist.

[nursoda]

Looks good. What I did to test because I had issue #4210 when I updated to 8.3.0_beta.1 in my test instance:

I disabled and removed polls 8.3.0_beta.1. In the database, I deleted all oc_polls_* tables and all polls lines in oc_migrations. I manually downloaded polls 8.2.2 zip from github and extracted it to the apps directory, enabled it. That took a while. I then updated to 8.3.0_beta.3 via occ upgrade. That was very quick. No errors here.