CI: build binaries for Big Sur architecture

[lrlna]

It seems like the built artifact does not work with Big Sur. We should add this distro to our testing matrix in github actions.

rover --version --log=trace
[1]    10997 killed     rover --version --log=trace

[EverlastingBugstopper]

Situation

We currently build release builds for x86_64-apple-darwin which has Tier 1 support meaning we have strong guarantees from Rust.

---

Problem

Big Sur requires building for a completely different architecture even if a given MacOS instance is running on the same hardware that worked with the x86_64-apple-darwin builds which is fascinating (and infuriating). The reason the architecture requirements are different is because Big Sur is meant to work on old Intel machines and the new M1 machines.

---

Solution

We need to build aarch64-apple-darwin which has Tier 2 support. This just means that Rust doesn't have their automated tests set up for that architecture.

My guess is that we will need to provide both binaries in our releases (unless the new architecture also happens to work on old versions of MacOS, which I doubt). Additionally, the curl installer and the npm installer will both need updates that detect which MacOS binary should be downloaded. Some extra research to be done there to see how best to determine that.

Unfortunately, GitHub Actions has put Big Sur builds into a private preview due to demand outpacing capacity. This significantly impedes our ability to make progress on this issue at the moment.

We will also need to start signing our binaries if we want our curl installer to work on Big Sur (generally a good practice anyways). Info on how to sign binaries can be found here

[abernix]

It's possible to build a Universal Binary that contains executable code for both architectures. It should be possible to build them on either hardware.

[abernix]

I do want to bring over (my own) comment that I feel is relevant from #230 (comment) (which was merged into this issue):

Have we considered using https://github.com/emk/rust-musl-builder or https://github.com/joseluisq/rust-linux-darwin-builder on this project in order to produce single binaries that run on multiple platforms? (I thought it may have been used or considered at an earlier phase.)

We had been using the former to build our binaries on Stargate successfully (it compiles inside a Docker image, but we have the pipeline built for it that this could mirror).

@EverlastingBugstopper noted as a response to this, that:

might be worth investigating but I will say I'm wary of bringing in the Docker dependency for our builds. [...] generally I find it way easier to debug cargo than docker.

It's fair to have hesitation here, but the burden of Docker as a dependency is already upon us since we're running cargo build in a Docker container already in GitHub Actions.

[abernix]

I'm failing at really correctly framing my actual point today (so I'm going to reconsider using my words today and I probably shouldn't have suggested this in the way I did above, so I edited my above comment to remove ramblings).

My actual point is: I think we should be cautious about introducing addition variant binaries when possible. Mac, Linux and Windows seem like good ambitions and I think we should consider multiarchitecture binaries when possible to stay within those constraints, if that makes more concrete sense.

[EverlastingBugstopper]

Reopening this as I think we should be able to produce a universal binary with cargo-lipo as you can cross-compile ARM binaries on x86_64 machines now... Maybe we could have done this before as well - it seems like @abernix had the right idea here, I think we just closed this because Rosetta 2 seemed good enough? Maybe not a good long term solution though (see #916)

cargo xtask dist on a mac machine should install cargo-lipo, run the appropriate rustup target add commands, and then run two separate cargo build --release --target {ARM/x86_64} commands, followed by the appropriate cargo-lipo command to combine the two binaries. We'll probably want to rename the binary which will also equire changes to the installers to point to the new GitHub release artifact permalink.

[EverlastingBugstopper]

We have released initial ARM support in v0.9.2-rc.0. Please give it a spin and let us know if you run into any issues using it.

Originally posted by @EverlastingBugstopper in #582 (comment)