Ensure universal links work for launcher stable rollback and for nightly/dev builds

[RebeccaMahany]

Background

My theory about why universal links wouldn't open correctly on development builds comes from the Preferred Application for a URL documentation at the bottom here.

If more than one application has been found [in the Launch Services database], apply the following criteria in the order shown:
a. Give preference to native OS X applications over those that run in the Classic emulation environment.
b. Give preference to applications residing on the boot volume over those residing on other file-system volumes.
c. Give preference to applications residing on a local volume over those residing on a remote volume.
d. If two or more versions of the same application have been found, give preference to the one with the latest version number.
If two or more candidate applications remain after all of the foregoing criteria have been applied, Launch Services chooses one of the remaining applications in an unspecified manner.

When I look through the Launch Services database for Kolide.app, I see that all the versions are listed as major.minor.patch, even when it's a dev version. (For example, the Kolide.app with version 1.6.7-4-g7396a0c has version 1.6.7 in the Launch Services database.) So, since Launch Services was treating all of our dev versions as the same version, we were falling through to the "unspecified" selection method. But publishing a new v1.6.8 should require Launch Services to select via criterion d instead -- and, tentatively, it looks like that's the case.

This means that universal links should just work for everyone on stable as-is: Launch Services will try to launch the newest version on disk, which is usually the correct, already-running version of launcher. However, in the case where we have to roll back stable to a prior version, Launch Services will still try to launch the newest version on disk, which is no longer the correct, already-running version.

Since stable rollback is pretty rare for launcher, I think we are safe to release the rest of universal link changes as they are, before addressing the rollback case. However, I do think we should address this issue, both to cover the rollback case and to make it easier to test universal links in development.

Requirements

Launch Services should always select the currently-running version of launcher, even when it is not the most recent version on disk.

Implementation

I think that we should add a darwin finalizer to autoupdate to handle registration with the Launch Services database. The finalizer runs after autoupdate but before launcher reload, which I think is an acceptable time to perform this change.

The finalizer should perform registration for the new app bundle -- basically what I did in this PR: #1731.

It should also un-register all other app bundles. I am unsure if we can do this via the objective-c API, but it is, at least, possible to do via the lsregister command-line utility. I think this is required -- when testing earlier, several of us noticed that just registering wasn't good enough to get Launch Services to select the correct version when there were multiple apps with the same version.

[directionless]

For example, the Kolide.app with version 1.6.7-4-g7396a0c has version 1.6.7 in the Launch Services database

I wonder if there's a simpler pattern here of making these version numbers closer to what we want.

In the past, I've played with the idea of replacing 1.6.7-4-g7396a0c with 1.6.7.4-g7396a0c and then maybe using 1.6.7.4 in the LS database. But I don't know how tractable that is

[RebeccaMahany]

That solves the problem with the dev builds, and I think it's a good idea. It wouldn't solve the rollback issue, but maybe we could tackle that separately -- I wonder if we could add a finalize step to autoupdate, where if we detect a rollback specifically, we unregister (and maybe also delete) the newer, rolled-back version of launcher.

[directionless]

I'm a little leery of the explicit unregister option. I think it ought be fine, but it also feels like manually poking things that might be fragile. So I'd favor being very narrow. Maybe we only do that when we downgrade. Or maybe we skip it because we downgrade so rarely.

[RebeccaMahany]

We don't need to support universal links at this time.