nar: fix executable permissions logic

[sandydoo]

This PR replaces Directories.getPermissions, which uses access to test whether the file is executable, with a mix of functions from the unix package to replicate the logic that Nix uses.

Nix doesn't use access to check whether a file is executable. It instead checks whether the owner executable bit is set.

When unpacking a NAR, Nix sets the executable bits for the owner, group, and other.

Fixes cachix/cachix#664.

Example in the wild

In the linked issue, the build of IINA contains multiple files with the extension .strings and permissions .r-xr-xr-x. Take for example, result/Applications/IINA.app/Contents/Resources/de.lproj/AboutWindowController.strings.
access returns false for X_OK when run on this file.
hnix fails to mark these files as executable when generating the NAR.

[sandydoo]

Oof, I'm having trouble creating a test for this. It's not entirely clear to me what makes these files so special. Maybe there's more to investigate 🤔

[sandydoo]

@Enzime figured out how to reproduce this cachix/cachix#664 (comment). We now have a working test case.

@sorki, how should we go about fixing CI?
The macos-latest (arm) runners now ship with a version of LLVM that's too new for GHC < 9.2. We can either switch to macos-13 (x86), or add a step to brew install LLVM 12, or use Nix, or remove a few versions of GHC 🙃

[sorki]

@sorki, how should we go about fixing CI? The macos-latest (arm) runners now ship with a version of LLVM that's too new for GHC < 9.2. We can either switch to macos-13 (x86), or add a step to brew install LLVM 12, or use Nix, or remove a few versions of GHC 🙃

Thanks for the pointers! Fixed in #283. I've kept only GHC 9.6 and added GHC 9.8. GHC 8.10.7 was there because of GHCJS which is now part of the mainline GHC anyway.

[sorki]

Thanks! I'll cut a release.

[sorki]

@sandydoo everything out!!

Reminder #233 (comment)