UI/updater: Add update channels

[derrod]

Description

This PR adds the option to select and update channel in the OBS Studio settings.

This implementation is based on https://github.com/obsproject/rfcs/pull/48

ToDo:

• [ ] UI/UX feedback
• [ ] Update server-side components
• [x] Cache list of branches after first load

Motivation and Context

We want users to be able to opt-into branches for easy switching between stable/beta and possibly test or nightly builds in the future.

How Has This Been Tested?

UI parts have been tested with a placeholder branches.json in %APPDATA%\obs-studio\update:

Example JSON

[
  {
    "default": true,
    "description": "Latest stable release",
    "display_name": "Release",
    "enabled": true,
    "manifest": "manifest.json",
    "name": "stable",
    "visible": true
  },
  {
    "default": false,
    "description": "Semi-stable test builds",
    "display_name": "Beta / Release Candidates",
    "enabled": false,
    "manifest": "manifest_beta.json",
    "name": "beta",
    "visible": true
  },
  {
    "default": false,
    "description": "Unstable/Unsigned nightly builds",
    "display_name": "Nightly",
    "enabled": true,
    "manifest": "manifest_nightly.json",
    "name": "nightly",
    "visible": true
  },
  {
    "default": false,
    "description": "Test Build to Fix issue #1234",
    "display_name": "Test, Issue #1234",
    "enabled": true,
    "manifest": "manifest_test_1234.json",
    "name": "test_1234",
    "visible": false
  }
]

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

• [x] My code has been run through clang-format.
• [x] I have read the contributing document.
• [x] My code is not on the master branch.
• [x] The code has been tested.
• [x] All commit messages are properly formatted and commits squashed where appropriate.
• [x] I have included updates to all appropriate documentation.

[derrod]

I've made a few changes once again to clean up some things. If anybody has a better idea than keeping track of available branches in OBSApp I'm happy to hear them.

Right now I believe there's also the slim chance of a race condition if the settings window is opened at the same time as the fetch thread finishes. Not sure if it's worth introducing a mutex there or if the risk associated with this is ultimately neglibible.

Edit: One way to address the potential race would be to block opening the settings until the update check has finished (similar to how it's blocked during Auth::LoadUI) but that may be a bad user experience. Mayhaps I will have to figure out how to introduce a sort of signal to refresh the list of branches in the UI once the update check thread has finished.

[derrod]

After some refactoring this PR is now down to a net gain of 300 lines. I have consolidated all signature-verified HTTP requests in the update code into one function and added a notification if a user's selected branch is no longer available.

I have not yet verified that the UI is not broken on Mac/Linux when the Windows-specific elements get deleted.

[derrod]

I'm planning to do a full test setup this week, there's also still something missing for checking the beta/RC revision. Also not sure what to do for nightlies, perhaps commit hash?

[derrod]

Added a WIP commit for relase/beta builds so they can be differentiated when checking for updates. This still doesn't address what to do for nightlies if we want to provide them. I'm considering that we could use a 64-bit unix timestamp that gets set when it is built instead of the regular OBS version for the internal check when dealing with nightlies. Or perhaps a more generic alternative could be to use the git commit hash of a build instead. That could be used in arbitrary branches without having to worry about setting some timestamp in cmake.

[derrod]

Added OBS_COMMIT as a new define that can be used to check if there's a new update instead. This only applies if the commit hash is set within the manifest, which I expect will only be done for non-release builds (e.g. nightlies, test builds, etc.)

[derrod]

I've done a full set of tests today with the following:

• Updating from "stable" to "beta" (with deltas)
• Updating from "beta" to "nightly" (without deltas)
• Downgrading from "beta" to "stable" (without deltas)

In doing so I hopefully fixed most of the outstanding bugs. There are some things we may have to consider related to downgrading as newer versions may contain additional files that would not get deleted unless the manifests were updated to include those files in the delete list.

Potential options here:

• Update the stable manifest when new things are added to beta builds (e.g. new plugins)
• Make it possible for the updater to read both the new and installed manifest, and decide deletions based on that
• Block plugins compiled against a newer libobs from loading, see: #6916

[derrod]

Made the following changes today so this PR can be considered "finished" and ready for review:

• Rebased on latest master
• Squashed all related commits together
• Fixed up getting the commit hash from git describe
• Removed default branch from JSON data, it will be hardcoded to "stable" instead
• Added windows/macos properties to branches
• Removed manifest filename from branches list (now created programmatically)

The latter are smaller changes in preparation for macOS support, which will be a separate PR based on this branch since it requires larger changes such as updating to Sparkle 2. That way it can be reviewed and worked on separately and won't block the Windows side of things.

[derrod]

~~In preparation for macOS support I've added a commit to merge win-update and nix-update into simply update. This includes a CMake change to use MbedTLS instead of Windows's crypto APIs as well as some general changes.~~

~~This has not been tested on Linux/macOS yet.~~

Removed to be part of #7723 to make it easier to review these changes in isolation.

[WizardCM]

TODO: Test with disabled updater.

[derrod]

TODO: Test with disabled updater.

Currently this doesn't do anything, I'll see if I can update it to hide/remove the new Update section when the flag is set.

Edit: Done in https://github.com/obsproject/obs-studio/pull/6907/commits/da4458c407cbf9e9eaba155d7b5a70a47f9fd4a0

Screenshots:

[derrod]

Rebased on master ~~plus a small behavioural change to disallow downgrades on the stable branch~~ and fixed some whitespace formatting.

~~This change is mainly so that people installing an RC manually don't immediately see a prompt to update (downgrade) to stable. A better solution to this problem would be to automatically set the selected channel to beta for beta/RC builds, but that is a change I'd prefer to add to #7723 since the large amount of refactoring and code cleanup it contains would essentially require me to do that twice otherwise.~~

I lied I found a decent solution that works as a one-time migration the first time a user runs a pre-release build (e.g. manual install). That way anybody deciding to manually install a pre-release build will not be presented with stable channel builds unless they have manually switched back or the beta channel has been disabled. We may sitll want to disallow dowgrades to be consistent between macOS and Windows and to avoid potential issues that may arise from dependency changes or plugin additions.

Note that if the beta channel is missing (not just disabled) at any point users will still be automatically switched back to stable. So if we release a beta1 with this we should make sure that at the very least an entry in branches.json does exist.

[derrod]

As expressed off-thread, I think we should merge this and iterate upon it as needed. If it proves problematic, we can revert it, make adjustments, and reland later.

Should I wait to hear back from @notr1ch regarding server-side path changes?

~~Also here is the branches.json file that should be signed and uploaded before the first release with this feaeture is published (inside a ZIP because github doesn't allow me to upload .json directly???): branches.zip~~ The file is now up.