Future-proof `phylum update`

[kylewillmon]

When phylum update is run, it will:

1. Confirm that the user is on a platform that supports self-update (i.e, aarch64-apple-darwin, x86_64-apple-darwin, or x86_64-unknown-linux).
2. Attempt an escape hatch update (details below)
3. Perform the steps exactly as explained for a fresh install here (i.e., download the zip, verify the signature, unzip it, and run ./install.sh)

Escape hatch update

To ensure that phylum update continues to work in the future even if we change our install process and/or release layout again, I will add an "escape hatch". Here are the steps I propose for the escape hatch:

1. Do an HTTP GET of https://update.phylum.io/update.sh and https://update.phylum.io/update.sh.minisig
2. If there is a 404 error or DNS error, go back to the normal install steps
3. If files are return, verify the signature and run update.sh to perform the update.

Originally posted by @kylewillmon in https://github.com/phylum-dev/cli/issues/187#issuecomment-1087583649

[peterjmorgan]

That's a cool idea! It reminded me of an idea from the initial implementation. Years of breaking software update implementations led me to The Update Framework awhile back: https://theupdateframework.io/

It might be a bit heavy-handed for this use, but I think some of the principles there could be helpful if we're going to re-design how the update implementation works.