Use cargo-dist to create binaries as release assets

[max-sixty]

We've had some good progress on creating binaries in #1883 & #762

In addition to those, we could also make lots of binaries with something like https://github.com/axodotdev/cargo-dist. I haven't looked at it in detail, but if it would let us do something like the "Assets" in https://github.com/BurntSushi/ripgrep/releases/tag/13.0.0 (screenshot below), that would be great.

[eitsupi]

cargo-dist doesn't support cross compile. axodotdev/cargo-dist#74
So at this point I think it is better not to use cargo-dist.

Another project that might be helpful for CI settings.
https://github.com/Nukesor/pueue

[eitsupi]

dist (cargo-dist) has made remarkable progress, and now it may even be possible to cross-compile binaries for arm64 Windows (though I'm not sure if that fits with this repository's caching strategy).

[max-sixty]

Yes dist looks like it's been really successful, +1

In general, I'd be keen to embrace tools like that — we get their enhancements for free and reduce the scope of "non-core" code in PRQL. Ofc requires assessing whether the tool will grow or lose support, which can be difficult ahead of time.

Also there are now ARM runners in preview for Linux. But not yet Windows, as you point out

[eitsupi]

The problem with adopting dist is that it generates its own GHA workflow file, which would not be compatible with our release strategy and cache.
As for the release, it increases the cache size and may cause the cache to disappear sooner.

[max-sixty]

Ah, that's a very good point; I hadn't thought of that. I had a quick look but didn't see a way to get around that in https://opensource.axo.dev/cargo-dist/book/ci/customizing.html

It would be fine if we only ran dist on releases, and that created a bunch of cache artifacts. But (I guess?) it also does the "test dry run" runs, which would constantly evict our cache...