Optimize Backup Order and Timeout Handling in Nextcloud CLI Updater

Is your feature request related to a problem? Please describe.
Currently, when updating Nextcloud via the CLI Updater, the backup process runs before attempting to download the update. This order may lead to unnecessary disk space consumption if the update download fails due to network issues, verification failures, or server unavailability. The updater may repeatedly create backups of the same version without proceeding to an actual update.

Additionally, there seems to be no timeout for the update download process. If a download stalls, it remains indefinitely in a "Downloading..." state, forcing manual intervention without clear logs explaining the failure. The updater.log does not provide sufficient details about such occurrences:

2025-03-14T12:59:05+0000 QtBCmgc4dO [info] createBackup()
2025-03-14T12:59:05+0000 QtBCmgc4dO [info] backup folder location: /srv/cloud.example.net-data/updater-ocrjeqbe66my/backups/nextcloud-31.0.0.18-1741957145/
2025-03-14T12:59:08+0000 QtBCmgc4dO [info] end of createBackup()
2025-03-14T12:59:08+0000 QtBCmgc4dO [info] endStep("3")
2025-03-14T12:59:08+0000 QtBCmgc4dO [info] executeStep request for step "4"
2025-03-14T12:59:08+0000 QtBCmgc4dO [info] startStep("4")
2025-03-14T12:59:08+0000 QtBCmgc4dO [info] downloadUpdate()
2025-03-14T12:59:08+0000 QtBCmgc4dO [info] getUpdateServerResponse()
2025-03-14T12:59:08+0000 QtBCmgc4dO [info] updaterServer: https://updates.nextcloud.com/updater_server/
2025-03-14T12:59:08+0000 QtBCmgc4dO [info] releaseChannel: stable
2025-03-14T12:59:08+0000 QtBCmgc4dO [info] internal version: 31.0.0.18
2025-03-14T12:59:08+0000 QtBCmgc4dO [info] updateURL: https://updates.nextcloud.com/updater_server/?version=31x0x0x18xxxstablexx2025-02-24T21%3A44%3A20%2B00%3A00+051e46a7a272300cf7c90b3e330fd1501fd6a996x8x3x17
2025-03-14T12:59:09+0000 QtBCmgc4dO [info] getUpdateServerResponse response: Array
(
    [version] => 31.0.1.2
    [versionstring] => Nextcloud 31.0.1
    [url] => https://download.nextcloud.com/server/releases/nextcloud-31.0.1.zip
    [web] => https://docs.nextcloud.com/server/31/admin_manual/maintenance/upgrade.html
    [changes] => https://updates.nextcloud.com/changelog_server/?version=31.0.1
    [autoupdater] => 1
    [eol] => 0
    [signature] => XDE87cPv/ephgFg+ReSdDfl+AF3+gXLnvxMCc0GrncidQN5f8RI9sEHmCcJxCD7s
ru9eqAzMuzatJTx5We2cYNMG14gzmXZ+4SJG2dvvqF4yZmq9NyqbwYSRzOsmlNzd
rjXTJd/RqbVK3z4+I76NVbsZkABST9ny+3uniJmj6Zp2x57h4wG1h0d9LA0aJGRv
aePATzTgwGvR85vCcxVDnfbMx3p31lRKJ/7uKCoUdh6PHEK7U2geFq53uKZO3/GF
5u8vcwWLle2YrU5hkBsuLXIwrMiy0ntC+NG4yTYEg12x6unAGTXJiFBiOJsLejHQ
EbS2o9PYNQR5OwBtSW0d8g==
)

2025-03-14T12:59:09+0000 QtBCmgc4dO [info] storage location exists

Describe the solution you'd like

1. Change the backup order: The updater should first verify that the update package can be successfully downloaded and verified before creating a backup. Only after ensuring a valid update package is available should the backup process commence.
2. Introduce a timeout mechanism: If the download process takes an unusually long time (e.g., more than 10-15 minutes without progress), the updater should automatically cancel the attempt and log an appropriate error message.
3. Improve backup retention handling: Ensure that multiple failed update attempts do not overwrite or unnecessarily accumulate backups of the same version, potentially pushing older useful backups out of rotation.

Describe alternatives you've considered
Right now I do manually housekeeping of backups.

Additional context
During an attempted update from version 30.0 to 30.0.1, the update process stalled at the "Downloading..." step with no timeout or error message. Repeated attempts created five identical backups within a short timeframe (~20-minute intervals because I manually killed the upgrader after 15 minutes of waiting). This highlights the need for better handling of both backup order and download failure scenarios.

Improving these aspects of the updater would enhance reliability and prevent unnecessary disk space consumption, while also reducing manual intervention for stalled downloads.

Start by tracing the CLI updater entry points named in the report: executeStep(), createBackup(), downloadUpdate(), and getUpdateServerResponse(). Confirm the current step ordering, download-stall behavior, logging, and backup retention handling; done means failed or stalled downloads do not create unnecessary backups and the failure is reported clearly.