Use a sparse bundle for /nix

[stephank]

This is a wild idea, and I'm not sure yet if we should go through with it, really. It came about from a short discussion in #nix-darwin. (Not sure where to find IRC logs.) Two parts:

• Is creating a disk image (sparse bundle) faster than an APFS volume? -> Some test runs on GitHub Actions still seem to indicate we can't really get below ~5s with this method. (Though Mac runners have very inconsistent perf)

• Then antifuchs came up with the brilliant idea: What if we commit a prepared, empty disk image? -> I did see a 3s run, so maybe? Again, perf is super inconsistent.

But, there are also downsides which make this questionable:

• No idea what the perf impact is of Nix builds on a disk image, compared to an APFS volume.
• Arbitrary upper bound to image size. We can probably go wild, because the 80G image in this PR is 33K compressed.

Another idea that's not in this PR: distribute an image with the Nix store and DB already present. Though, we'd still need to compress the image, so I think this essentially just moves the unarchive step around in the process. Sounds like there's little benefit.

With the super inconsistent performance of Mac runners, I'm really not sure any of this is worth the trouble. This PR is really just to have the effort documented and maybe some discussion. 🙂

For reference, the command used to create the image is:

hdiutil create -size 80GiB -fs APFS -type SPARSEBUNDLE -volname nix -nospotlight ./nix.sparsebundle

[rickynils]

Interesting approach! If we somehow can show that this actually cuts down the (average) install time, I think it is worthwhile.

I think that distributing a complete disk image with the store and db fits slightly better with our current approach of building and publishing the nix store as part of the GitHub release. It will make the Linux and MacOS installation scripts deviate slightly more, but if we can avoid the committed disk image I think its a win. Though, the empty disk is a one time thing so I could live with that too.

[wolfgangwalther]

Would this fix #43, too?