This matches what we want for blobs.

Trees are still in progress - we need a way to symlink to other
objects, using that to determine ca.

This is really bad and dangerous! But Git migration to sha256 is still
a ways away:

https://lwn.net/Articles/811068/

So we need to allow it for the time being.

We need access to other things in the store. This is kind of dangerous
though if things are added in the wrong order�.

This is needed to create files based on git permissions

This updates the remote protocol to try to handle sha1 hashes.

This is more direct.

We need both to properly mess with the file system. storeDir goes into
the hash while realStoreDir is what we read & write to.

Need to use the htSHA1 we were given, don’t recompute.

this makes maintanence easier

This reverts commit 7b6186d.

narHash is the hash of the nar, not the git objects.

We need to dump path and dump git here so that the hashes match what
is expected elsewhere.

This should always use sha1 hash type, but we want to make sure the
caller knows that. So just throw an error instead of ignoring hashAlgo
on Git ingestion.

symlinks should be relative so that they look like:

  ../s5c0hnz9qfnpnn1bszfxicgz21d1fam3-dummy3

instead of

  /build/nix-test/store/s5c0hnz9qfnpnn1bszfxicgz21d1fam3-dummy3

This way our hashes will work with any real store dir. Note that
/nix/store is still embedded in the store entry function.

this shouldn’t be needed - FdSink handles this for us.

Symlinks are resolved in the nar format so we end up with references
to the real store dir. Copying avoids this and gives us a stable hash.

Also update the ParseSink api with two methods:

  - copyFile
  - copyDirectory

both are needed to properly implement git parsing.

libc++fs isn’t alway available