Disallow CA paths from referring to non-CA paths

[edolstra]

Currently CA paths can refer to non-CA paths:

$ nix path-info --json /nix/store/ap2nhrpfjin5ng881mgl4pmrzmsp6cj0-patchelf-0.13 | jq .[].ca
"fixed:r:sha256:1i4ygjm0jax3q3gcayv9g1mff0711xyfg87in8l4m0rbqyss5rcn"

$ nix path-info --json -r /nix/store/ap2nhrpfjin5ng881mgl4pmrzmsp6cj0-patchelf-0.13 | jq .[].ca
null
"fixed:r:sha256:1i4ygjm0jax3q3gcayv9g1mff0711xyfg87in8l4m0rbqyss5rcn"
null
null
null

This seems like an undesirable property, since it means that a top-level CA path does not "lock" its dependencies.

@thufschmitt What do you think?

[thufschmitt]

Yes, that was intentional, for two reasons:

1. Since the hash rewriting is only a heuristic, it seemed safer to provide a local escape hatch (saying that a specific derivation should be input-addressed while all the rest would be CA);
2. Enforcing everything to be CA can make it hard to interact with external derivations − for example my system config is globally content-addressed, but I also include some packages from a few external flakes (and which are input-addressed).

Now, it seems that 1. was essentially a theoretical concern (there has been a couple of CA-related breakages in nixpkgs, but all easy to fix and due to https://github.com/NixOS/nix/issues/4764 and not the hash rewriting) so that’s not a really strong point anymore.

For 2, maybe we could expose makeContentAddressed as a builtin so that we can rewrite on-the-fly any input-addressed derivation output that we’d want to use?