Updater server configuration vision

[MorrisJobke]

Right now the updater config is fully designed around the concept of channels and in there are the different versions a Nextcloud wants to upgrade from. That means that if there is a release of 19 - like 19.0.10, then the config for the beta and stable channel needs to be adjusted and in there once for the upgrade from 18 and once for the upgrade from 19. So in the end one has to add 4 times the config for this one release. Plus all the changes to the tests as they are build against this config. It also has workarounds to accomplished to only upgrade from 18 to 19 for example once the latest patch level of 18 is already installed.

In general this config is quite error prone due to all the duplication. A better approach would be to just have a long list of available releases that the updater than chooses from based on our constraints. Something like "only provide the next major version once the latest available release of the current major version is installed". Or "provide the latest patch release only to 20 %". In this way also automating the updater server update is easier as it is just adding the new release to the list of available releases instead of replicating this logic to generate the config.

The big question here is:

1. Should this be handed in via an API in the updater server itself? That would then result in something like the appstore. Maybe it should then be added to the app store directly? How does the staging and testing work? How can we prepare releases there?

2. Or should it be handled like now to just have a long list of releases as some sort of serialized data and check it in into the updater server repo. Then the API would be a pull request and the deployment would be the same as now as there would be a testing updater server and a production updater server.

cc @LukasReschke @rullzer @blizzz @skjnldsv