That way things (like `nix flake check`) can evaluate the `app` outputs
without having to build anything

~/.bashrc should be sourced first in the rc script so that PATH &
other env vars give precedence over the bashrc PATH.

Also, in my bashrc I alias rm as:

  alias rm='rm -Iv'

To avoid running this alias (which shows ‘removed '/tmp/nix-shell.*'),
we can just prefix rm with command.

Split the parsing of an `App` and its resolving

…velop

Source bashrc first in nix develop

Accidentally removed in ca96f52. This
caused `nix run` to systematically fail with

```
error: app program '/nix/store/…' is not in the Nix store
```

Restore an accidentally suppressed negation

When you have a symlink like:

  /tmp -> ./private/tmp

you need to resolve ./private/tmp relative to /tmp’s dir: ‘/’. Unlike
any other path output by dirOf, / ends with a slash. We don’t want
trailing slashes here since we will append another slash in the next
comoponent, so clear s like we would if it was a symlink to an absoute
path.

This should fix at least part of the issue in
#4822, will need confirmation that
it actually fixes the problem to close though.

Introduced in f3f2287.

Fix extra slash in canonPath output

Move the `closure` logic of `computeFSClosure` to its own (templated) function.

This doesn’t bring much by itself (except for the ability to properly
test the “closure” functionality independently from the rest), but it
allows reusing it (in particular for the realisations which will require
a very similar closure computation)

Align all the worker protocol with `buildDerivation` which inlines the
realisations as one opaque json blob.
That way we don’t have to bother changing the remote store protocol
when the definition of `Realisation` changes, as long as we keep the
json backwards-compatible

Currently never used, nor set but will be useful shortly

Only considers the closure in term of `Realisation`, ignores all the
opaque inputs.

Dunno whether that’s the nicest solution, need to think it through a bit

Otherwise registering the realisations on the remote side might fail as
it now expects a complete closure