feat: improve updater for tauri v2 & handle pre-release

[mmrrnn]

Description

This pull request introduces support pre-release versions, placed in settings. It also contains creating UpdatesManager on the backend side, which is kinda refactor of the previous updater implementation for Tauri V1.

• Added pre_release field to AppConfig, placed in "General Settings"
• Moved updater logic to the backend, created UpdatesManager to handle all related logic and provide straightforward commands. It gives us more control over the updates flow and far more space for debugging.
• Updater Dialog UI is not changed, it's just "dumb" and react to the events from rust. User shouldn't see any significant change

How it works

• When the pre-release version is enabled, the application retrieves the latest versions from alpha-latest.json. Disabling this flag immediately updates the application to the non-pre-release version.

• When the pre-release version is disabled, the application fetches the latest versions from latest.json. From the user's perspective, there should be no significant changes. Enabling this flag instantly updates the application to the pre-release version.

Motivation and Context

#518 - Since we upgraded Tauri to v2, we can now handle pre-release versions. We use Tauri Dynamic Update Server to achieve this. This required us to move updater logic to the backend.

What process can a PR reviewer use to test or verify this change?

Testable on development environment. Play with this by changing

• tauri-conf.json version to set the "current" app version
• latest.json version to set the latest non-pre-release version
• alpha.json version to set the latest pre-release version

Toggle "pre_release" flag in the settings to switch between these app versions, turn on/off the auto_update flag and see how it affects the app. You can also update the app via "Release Notes" section

[brianp]

Looks good to me, and seems to be working well enough in development.

Functionality change
Right now the current implementation permits downgrades if the latest.json, or alpha-latest.json has a lower version. We do not want downgrades to happen in this case. As we sometimes utilize the ability to bump a version up, have users download it, and then set the version lower. To rollout to only a small amount of people.

Ideally the only time we should allow downgrade is if the user is turning off pre-release versions.

When toggling the pre-release, We should also alert the user that we're going to restart with their upgraded or downgraded version.

UX Change
Put the pre-release setting directly after the auto-update setting.

[mmrrnn]

• enabled downgrade only when user switches off pre-release version
• removed redundant check for update when setting up the app
• moved pre-release toggle button right below the one for auto update

[mmrrnn]

To sum up: app will only allow to downgrade, when user manually switches off the pre-release mode

[mmrrnn]

Sorry for lags, cancelled twice and then confirmed:

Screencast.from.12-10-2024.05.09.45.PM.webm

[Tas4tari]

Tested on Windows 11, app version 0.8.25. I see the pre-release toggle displayed below the auto update option & I was able to enable/disable the option:

Disable pre-release version: