Add haskell.lib.incremental utility

[Gabriella439]

This adds a new incremental utility for Haskell CI that supports incremental builds based on the approach outlined in this blog post:

https://harry.garrood.me/blog/easy-incremental-haskell-ci-builds-with-ghc-9.4/

The basic idea is that instead of Nix doing a full build for a package, we split every build into two builds:

• A full build at an older point in time

  e.g. a daily or weekly time boundary

• An incremental build relative to the last full build

  This incremental build reuses the build products left over from the most recent full build.

In order to do this, though, we need a way to "snap" a package's git source input to an earlier point in time (e.g. a daily boundary or weekly boundary). This would allow multiple incremental builds to share the same full rebuild if they snap to the same time boundary.

The approach I went with to make that possible was to extend Nix's builtins.fetchGit to support a new date argument and you can find the corresponding PR for that here:

NixOS/nix#7362

That is why the incremental utility added here requires a sufficiently new version of Nix (one that would incorporate that change, presuming it is merged).

This also requires GHC 9.4 or newer in order to pick up a fix to GHC's change detection logic, as described in more detail in the above blog post.

However, if you satisfy those requirements then this works exactly the way you'd expect: all of the incremental builds only have to build the diff since the last time boundary. Moreover, if CI caches the full build then developers can also run nix build locally and only have to build the diff, too.

[Gabriella439]

Needless to say, this should not be merged until NixOS/nix#7362 is merged, but I'm putting up this PR for review anyway since it informs the upstream PR to Nix

[sternenseemann]

Please remove this function from the PR. If I understand it correctly, it depends on NixOS/nix#7362 – “presuming it is merged” is presumed too much. In general I also want to keep anything out of haskell.lib that depends on unreleased Nix features.

Presumed too much also in the sense that I believe the fetchGit feature will be quite controversial.

[Gabriella439]

Just to clarify: I don't intend to merge this PR until the upstream change to Nix is merged and released (e.g. as Nix 2.12.0 or whatever version it comes out in), upon which I'd change requiredNixVersion here to reflect the Nix version releasing the fetchGit feature. I expect it could be a while before this PR can be safely merged, so I'm not in a rush.

As I mentioned in the pull request discussion, the only reason I opened up this PR right now is not because I'm in a hurry to merge this change, but rather so that this Nixpkgs PR can inform the upstream PR to Nix.

[Gabriella439]

I rebased this on top of #203963 because the .dylib workaround interferes with the incremental build on macOS. Specifically, the package.conf surgery entailed by the .dylib workaround causes downstream modules to be rebuilt due to Cabal's change detection

[Gabriella439]

Sorry for the unnecessary pings. This was a bad rebase on my part. I'll fix this