Due to Nix bug <NixOS/nix#11503>,
`builtins.filterSource` and chroot stores interact in a confusing
and broken way that breaks `lib.fileset`. This means that uses of
the API inside Nixpkgs keep breaking the NixOS installer, blocking
the channel. The resulting error messages are inscrutable (they look
like “the installer test is trying to download `curl`…?” and
eventually bottom out in a derivation that has the wrong `outPath`
because of the chroot store causing an incorrect `lib.fileset` result).

Whenever this happens, someone (well, in practice K900 or I)
has to bisect the change that introduced it and remove the use of
`lib.fileset`. This has happened at least three times in the past
four months (I believe I might actually be missing one here, but
these are the ones I remember and could easily dig up):

* <NixOS#340046>
* <NixOS#352491>
* <NixOS#369459>

The options I see here are:

1. Forbid use of `lib.fileset` within Nixpkgs until the Nix bug is
   fixed. This is the approach taken here. External users of Nixpkgs
   can continue to use the API as normal, but using it from within
   something that affects any release jobset `outPath`s will cause an
   evaluation failure with a hopefully‐helpful error message.

2. Forbid `lib.fileset` and also all of the other library APIs that use
   `builtins.filterSource`. I’m happy to do this, but so far none of
   those have broken the installer, so I decided to start small and
   worry about the others if they end up causing a problem in practice.

3. Forbid `builtins.filterSource` directly. This is hard and would
   require more invasive `builtins.scopedImport` crimes to do at
   evaluation time. I think this would realistically have to be done in
   something like nixpkgs-vet instead and I didn’t have much luck
   shoehorning a check like this into that codebase when I tried.

4. Fix the Nix bug. This would be great! But also it doesn’t seem to be
   happening any time soon, it seems difficult to fix in a way that
   doesn’t subtly break compatibility with the previous semantics, and
   arguably the fix would need backporting all the way back to 2.3
   given our minimum version policy.

5. Do nothing; have people continue to innocuously use `lib.fileset`
   throughout Nixpkgs, breaking the installer whenever one of them
   sneaks in to that closure, causing the channel to be blocked and
   requiring expensive bisections to narrow down the inscrutable test
   failure to the package using `lib.fileset`, which then needs moving
   back off it. This sucks for the people who keep having to track it
   down, holds back important channel bumps, and the criteria for when
   it’s okay to use `lib.fileset` are not realistically possible to
   teach to all contributors.

I'd be happy to work on (2) as an alternative; (3) would be difficult
and seems like overkill, (4) is not really something I trust myself
to do and wouldn’t address the immediate problem, and (5) isn’t
sustainable. I think that the current approach here is the best
trade‐off for now, as `lib.fileset` seems to be the only prominent
user of the `builtins.filterSource` API that works with full store
paths, exposing it to the Nix bug. It’s unfortunate to lose the
nice API, but since we can’t rely on it to produce correct results
and the channels keep getting blocked as a result, I don’t think
we really have an alternative right now.

Due to Nix bug <NixOS/nix#11503>,
`builtins.filterSource` and chroot stores interact in a confusing
and broken way that breaks `lib.fileset`. This means that uses of
the API inside Nixpkgs keep breaking the NixOS installer, blocking
the channel. The resulting error messages are inscrutable (they look
like “the installer test is trying to download `curl`…?” and
eventually bottom out in a derivation that has the wrong `outPath`
because of the chroot store causing an incorrect `lib.fileset` result).

Whenever this happens, someone (well, in practice K900 or I)
has to bisect the change that introduced it and remove the use of
`lib.fileset`. This has happened at least three times in the past
four months (I believe I might actually be missing one here, but
these are the ones I remember and could easily dig up):

* <#340046>
* <#352491>
* <#369459>

The options I see here are:

1. Forbid use of `lib.fileset` within Nixpkgs until the Nix bug is
   fixed. This is the approach taken here. External users of Nixpkgs
   can continue to use the API as normal, but using it from within
   something that affects any release jobset `outPath`s will cause an
   evaluation failure with a hopefully‐helpful error message.

2. Forbid `lib.fileset` and also all of the other library APIs that use
   `builtins.filterSource`. I’m happy to do this, but so far none of
   those have broken the installer, so I decided to start small and
   worry about the others if they end up causing a problem in practice.

3. Forbid `builtins.filterSource` directly. This is hard and would
   require more invasive `builtins.scopedImport` crimes to do at
   evaluation time. I think this would realistically have to be done in
   something like nixpkgs-vet instead and I didn’t have much luck
   shoehorning a check like this into that codebase when I tried.

4. Fix the Nix bug. This would be great! But also it doesn’t seem to be
   happening any time soon, it seems difficult to fix in a way that
   doesn’t subtly break compatibility with the previous semantics, and
   arguably the fix would need backporting all the way back to 2.3
   given our minimum version policy.

5. Do nothing; have people continue to innocuously use `lib.fileset`
   throughout Nixpkgs, breaking the installer whenever one of them
   sneaks in to that closure, causing the channel to be blocked and
   requiring expensive bisections to narrow down the inscrutable test
   failure to the package using `lib.fileset`, which then needs moving
   back off it. This sucks for the people who keep having to track it
   down, holds back important channel bumps, and the criteria for when
   it’s okay to use `lib.fileset` are not realistically possible to
   teach to all contributors.

I'd be happy to work on (2) as an alternative; (3) would be difficult
and seems like overkill, (4) is not really something I trust myself
to do and wouldn’t address the immediate problem, and (5) isn’t
sustainable. I think that the current approach here is the best
trade‐off for now, as `lib.fileset` seems to be the only prominent
user of the `builtins.filterSource` API that works with full store
paths, exposing it to the Nix bug. It’s unfortunate to lose the
nice API, but since we can’t rely on it to produce correct results
and the channels keep getting blocked as a result, I don’t think
we really have an alternative right now.

(cherry picked from commit 8725e46)

Due to Nix bug <NixOS/nix#11503>,
`builtins.filterSource` and chroot stores interact in a confusing
and broken way that breaks `lib.fileset`. This means that uses of
the API inside Nixpkgs keep breaking the NixOS installer, blocking
the channel. The resulting error messages are inscrutable (they look
like “the installer test is trying to download `curl`…?” and
eventually bottom out in a derivation that has the wrong `outPath`
because of the chroot store causing an incorrect `lib.fileset` result).

Whenever this happens, someone (well, in practice K900 or I)
has to bisect the change that introduced it and remove the use of
`lib.fileset`. This has happened at least three times in the past
four months (I believe I might actually be missing one here, but
these are the ones I remember and could easily dig up):

* <NixOS/nixpkgs#340046>
* <NixOS/nixpkgs#352491>
* <NixOS/nixpkgs#369459>

The options I see here are:

1. Forbid use of `lib.fileset` within Nixpkgs until the Nix bug is
   fixed. This is the approach taken here. External users of Nixpkgs
   can continue to use the API as normal, but using it from within
   something that affects any release jobset `outPath`s will cause an
   evaluation failure with a hopefully‐helpful error message.

2. Forbid `lib.fileset` and also all of the other library APIs that use
   `builtins.filterSource`. I’m happy to do this, but so far none of
   those have broken the installer, so I decided to start small and
   worry about the others if they end up causing a problem in practice.

3. Forbid `builtins.filterSource` directly. This is hard and would
   require more invasive `builtins.scopedImport` crimes to do at
   evaluation time. I think this would realistically have to be done in
   something like nixpkgs-vet instead and I didn’t have much luck
   shoehorning a check like this into that codebase when I tried.

4. Fix the Nix bug. This would be great! But also it doesn’t seem to be
   happening any time soon, it seems difficult to fix in a way that
   doesn’t subtly break compatibility with the previous semantics, and
   arguably the fix would need backporting all the way back to 2.3
   given our minimum version policy.

5. Do nothing; have people continue to innocuously use `lib.fileset`
   throughout Nixpkgs, breaking the installer whenever one of them
   sneaks in to that closure, causing the channel to be blocked and
   requiring expensive bisections to narrow down the inscrutable test
   failure to the package using `lib.fileset`, which then needs moving
   back off it. This sucks for the people who keep having to track it
   down, holds back important channel bumps, and the criteria for when
   it’s okay to use `lib.fileset` are not realistically possible to
   teach to all contributors.

I'd be happy to work on (2) as an alternative; (3) would be difficult
and seems like overkill, (4) is not really something I trust myself
to do and wouldn’t address the immediate problem, and (5) isn’t
sustainable. I think that the current approach here is the best
trade‐off for now, as `lib.fileset` seems to be the only prominent
user of the `builtins.filterSource` API that works with full store
paths, exposing it to the Nix bug. It’s unfortunate to lose the
nice API, but since we can’t rely on it to produce correct results
and the channels keep getting blocked as a result, I don’t think
we really have an alternative right now.