Migrate to Velopack

[smallketchup82]

Codependency:

• https://github.com/ppy/osu/pull/28743

I highly recommend reading me and caesay’s discussion in the osu!dev discord to get an idea of what’s going on here.

Velopack

This is one PR (and the main PR since it contains the largest diff) in a series of PR's to migrate osu!lazer's update framework from Clowd.Squirrel to Velopack, the "next generation" of Clowd.Squirrel.

Why the migration?

Clowd.Squirrel has numerous issues that have long plagued osu!lazer and lazer's development as a whole. Velopack has the following differences compared to Clowd.Squirrel (not sure if they're differences, but it is what it is):

• Cross compiling: Velopack allows for compiling a package for a different operating system rather than the current one, saving time.
• Automatic shortcut management: Velopack takes care of setting up shortcuts, allowing us to remove our own shortcut creation logic
• Release channels: Velopack supports creating numerous release channels, and the methods to do so are very intuitive. For example, It would be entirely possible to provide a new release stream for osu!lazer based on the latest github master commit, tag, etc.
• Automatic installers for every platform: Even if the application is packaged portably, say an AppImage on linux, Velopack will facilitate downloading the new AppImage and replacing the old one.
• Static executable location: Velopack keeps a folder called current which is a symlink to the most recent release. This allows features like Windows Associations to not require updating each time the game launches.
• Easier code signing: Code signing is much easier to do on Velopack than it is on Clowd.Squirrel, which allows us to do less on our end
• Automatic downgrading upon switching release channels or if a release gets pulled

All of these would allow for a much simpler osu-deploy, a much cleaner osu!lazer, more opportunities in the future (release channels) and a better user experience for the end user.

So how's it going to work?

I'm going to be basing my osu-deploy branch off of caesay’s branch, while keeping it in line with recent osu-deploy updates and updates to velopack. The same can be said for my osu!lazer branch, though I unintentionally reimplemented caesay's branch instead of basing it on his branch.

Velopack is more or less a drop in replacement for Clowd.Squirrel, so all that really needs to be done is to remove lines and change existing lines to use Velopack instead. Velopack will automatically manage reading from Squirrel's RELEASE files and migrating clients onto Velopack, so there is no work needed to be done on that front.

Both me and caesay want to discuss things before doing things, so as to not waste effort. Which is why this PR, while it is in it's draft phase, will be the main place for discussion on Velopack migration, design choices, considerations, etc.

What needs to be done?

This mostly means what needs to be done before this PR is ready for review, and the osu-sided PR is ready for review.

• [x] Reimplement caesay's branch
• [x] Wait for upstream changes (https://github.com/velopack/velopack/issues/156) to get merged

Differences from caesay's branch

• Decided to not change the GithubRelease and GithubObject models, and also not add a GithubReleaseHelper
  • Mainly did this because I believe it's out of scope of this PR, and would like to keep the file change count low. This movement of logic is better suited for a future PR
• Decided not to add a Log class
  • For the same reasons as the last. This is better suited for a future PR/refactor
• Removed unused (probably meant for the future) functions
• Shuffled around the logic in caesay's branch to try and reduce the amount of if statements needed
• Updated old stuff to work with the latest version of Velopack and osu-deploy (e.g. appdir handling)'

Final notes

Not much to say here. Maintainers can edit the branch as needed. @caesay if you want to make changes to my branch, I'm okay with either a PR on my fork or a git patch. This should close #125 as a side effect (as vpk pack will output a nupkg, removing the need for nuget.exe). And this will make all open PR's obsolete.