Update Modes

[jameskerr]

Add different modes to auto update.

• Check what "vibracy" looks like on windows
• Write code to handle linux auto updates.
• Make sure it works as expected.
• Update the "download progress code"

Closes #1211
Closes #2303

[philrz]

I've been doing some testing of this branch at commit 88e21cc using the Dev builds created here. This build intentionally has its version string in package.json set to 1.4.0 with the knowledge that the latest GA Zui release on GitHub is currently 1.4.1, so if the update functionality is behaving as we'd expect, it would discover 1.4.1 and offer to update to it.

The tl;dr is that I've found some happy paths where it seems to be working well, and also some buggy variations. I'll start in this comment by documenting what's working, then I'll open up separate comments with each of the observed bugs.

The videos below show it behaving as expected in a "happy path" of default Zui Settings after a fresh install on all OSes as long as:

1. The app has been already launched & closed at least once before, and,
2. The Check for updates... Setting is configured to On Startup

This first video shows it behaving as expected on macOS.

Happy.mp4

Important things to note:

1. The Check for updates... setting is reported accurately in the main.log with the line shown that reads Starting updater in mode: startup
2. After clicking Install, no further action was required on my part. The newer version of the app was installed and the app relaunched into the new version all automatically.

Windows has a similar happy path, with the variation that after I click Install the newer version of the app is downloaded automatically but I'm placed into an installer workflow. If I proceed with the couple clicks that are highligthed by default, the app ultimately does relaunch into the new version.

Windows-Happy.mp4

Linux also has a fine happy path. Here the variation is that after clicking Install the user is brought automatically to the https://www.brimdata.io/download/ page in their browser, which is in keeping with the understanding that we've always lacked full auto-update support on Linux. The Linux Installation guidance on the Zui docs site already advise the user on the details of manual upgrades being required on Linux, so we're in good shape here.

Linux-Happy.mp4

Without posting yet another set of exhaustive videos, I'll also note another positive finding I had when testing on each OS and clicking Later when notified of the availability of the newer version and given the option to update. In each case when I clicked Later I saw the desired result of remaining on the currently installed release. This is actually a vast improvement over what we had before on macOS and Windows. In the past, clicking Later had the effect of only postponing the upgrade until the next time the app was closed and relaunched. That is, even when clicking Later, the new version was still downloaded and installed in the background, such that the next time I closed and relaunched the app I'd be on the newer version. Part of why I've felt the functionality in this PR is needed so badly is because what we had in the past made it effectively impossible for a user to remain on an older version, unless of course they happened to be completely cut off from Internet access. So, more 👍.

[philrz]

All bugs I'd found when testing the branch seem to have been resolved, so I'm 👍 on this merging. Once it's merged I'll plan to do a final/exhaustive verification of all permutations by creating a personal fork of Zui where I can do true GA-style older/newer builds with all the necessary secrets as a final assurance that everything that worked with Dev builds should work just as well when we do the next GA Zui release.