Future-proof installer script and re-introduce target triplets

[abernix]

This is meant to reintroduce the Target Triplet pattern which was first introduced in #1393 and the #1405 follow-up, which were intentionally reverted prior to the 0.12.0 release because the existing installer script wouldn't correctly continue to pin the version in a way that wouldn't break existing users had we deployed that technique. The reason that was challenging is that we hadn't fixed the underlying issue.

This PR has meaningful individual commits that are worth reviewing. The first two are literally cherry-picks from previous iterations, followed by other commits which solidify more durable behavior. The previous installer should continue to work just fine, but as we're doing a major version bump, I suspect even if that doesn't work out we'll be okay for the long-term.

This also relates to (and still blocks) #1397.

There's some TODO items that we should account for before re-landing this, in particular, adopting the same pattern that Rover used which was more defensive in the way that it preserved the installation script within the Git tag of the release, making it possible for the Orbiter to reliably redirect a user to a immutable version of the install script that was current as of the time of the release. (Rather than the method of today where the current release installer tries willingly to install any past release (which will fail after the target triplets change.)

We originally cargo culted the Rover installer when making the Router installer exist, but a number of nuanced differences have emerged in it. This updates the installer in a variety of ways to align with that and provide a more durable installer experience:

• The version of the installer is now embedded in the script itself as PACKAGE_VERSION. This pushes the burden of determining what latest is to [Orbiter] (our AWS Lambda function which runs in Netlify). It also allows the file that is in the commit that is in the Git release tag to be the installer that knows how to install that version best.

  In other words, this gives us freedom to make material changes to the way our installer process without relying on (the current) behavior which leaves every version's installer needing be able to install every version of the Router which is problematic in a variety of ways. For example, if you want to change the filenames in the release (or the architecture negotiation), which brings me to my next point.

• We no longer use positional parameters to the install script to indicate the version we're going to solve. The previous method wasn't durable for the reason listed above (and the reason we couldn't land what should have been a relatively simple change to the file formats of our release artifacts). It is Orbiter's responsibility to point to the correct version of the installer for a particular version of the Router and pinning a version should be done via the Orbiter URL itself. Behind the scenes that redirects to the Git tag of the release. This also allows us to track our download counts through a centralized point. See this code for more details.

  The way to install the latest version of the Router — always — remains as it was:

  curl -sSL https://router.apollo.dev/download/nix/latest | sh

  The way to install a specific version of the Router also remains as it was:

  curl -sSL https://router.apollo.dev/download/nix/v0.15.1 | sh

• Introduces more specific filenames which use a standardized representation of the architecture - "target triples". Not only is this the pattern that we use on Rover which is meaningfully important for reducing cognitive overhead, but this it is also a more common representation in the general sense and necessary to support a full range of binaries. Since Rover actually does the downloading, this also simplifies how it needs to think about our release artifacts, at least in the near term. Also there is now a v in front of the version in the tarball name instead of being yet again subtly different than Rover.

• Adds support for wget, in addition to curl for downloading the release artifact from GitHub. Containers often don't have either and sometimes just one or the other. We literally have the code written already to negotiate between the two, so supporting both seems fine. It's also just one less diff between the files.

• Adds a very necessary assertion that mktemp exists on the system. Again, one less difference between what Rover does and Router and meaningful UX for installers.

Fixes #1385

[SimonSapin]

I find this to be an uncomfortable amount of shell script code, but oh well

[garypen]

Looks good. shellcheck complained about the style thing, so I thought I'd mention it. Feel free to ignore since that was already there.

[garypen]

NIT: this is considered to be better style (SC2181)

Suggested change

	downloader "$_url" "$_file"
	if [ $? != 0 ]; then
	if ! downloader "$_url" "$_file"; then

[Geal]

could this be overridden by an environment variable or an argument?

[abernix]

I mean, yes, but again, same comment as #1433 (comment), the point is that is not durable because the package installer might change over time based on the version. It is very intentional that it does not allow installing different versions. 😸

If you want a different version, you change the version in the curl install URL path itself. That lets us track the actual invocations of the installer and change the installer over time with the versions.

[abernix]

A future step should automate bumping this, in the same way that it's already automated on rover.

[abernix]

I mean, yes, but again, same comment as #1433 (comment), the point is that is not durable because the package installer might change over time based on the version. It is very intentional that it does not allow installing different versions. 😸

If you want a different version, you change the version in the curl install URL path itself. That lets us track the actual invocations of the installer and change the installer over time with the versions.