Pull resources from NAR directly

[Thesola10]

Right now the static-bins output just crossed 100MB uncompressed, which means it now has the honor of slamming into cachix/cachix#619. (UPDATE: they kindly pushed back the size limit cachix/cachix#619 (comment), but the fragility of Nixie's current approach is still evident)

We need a simpler, more Nix-y way to retrieve files from within the derivation. My idea now that #16 has been merged, is to try and write a streamed NAR parser in Amber, which would in turn provide exact offsets to download a file from within the NAR, using minimal bandwidth (and therefore memory) to perform the lookup in the first place.

The ideal implementation would be a Jura an Amethyst package, which implies a couple fixes to upstream projects first:

• Allow package locking ArjixWasTaken/amethyst#7
• Bootstrap process for building Amethyst in Nix ArjixWasTaken/amethyst#11

[Thesola10]

Well this is annoying... Cachix only supports zstd and xz as compression methods. zstd is completely out of the question, and xz isn't much better (not preinstalled on macOS for instance).

I really don't want to give up on the Nix cache approach since it ensures any version of the script can handle its resources format, so I'll have to look into self-hosting a Harmonia cache or something.

I'll keep working on amber-nar in the mean time.

... then again the static xz executable is tiny (370k)... and the static-bins derivation is only needed on supported platforms...

[Thesola10]

Update! Cachix now serves zstd archives even if xz was explicitly set on the project page. It looks as though I'd have to ship zstd in the script tarball itself.
The reference zstd is rather large at 1.1MB and I don't want to hard-dep on a relatively new tool.

On the other hand the source build process is an upstanding citizen of pure, dependency-less C. 10 megabytes of it. Nah.