macos: recover paths that restart at a symbolic link

[LalitMaganti]

Summary

Recovers the paths of files opened through a relative symbolic link. Without this, #29 resolves them against the wrong directory.

Fifth of seven steps towards #2. Stacked on #30.

Why

When a lookup follows a relative link, the kernel reports the link's text and the rest of the path. It does not report the directory that holds the link. A read through Homebrew's ../Cellar links or the SDK's MacOSX.sdk link therefore arrives as a path with no starting point. Resolving it against the process's directory produces a path that does not exist.

Changes

• Vnodes: with each lookup, the kernel reports a vnode, which identifies the file it found. When any process looks a file up by its absolute path, Buildprof remembers that path for the vnode. A later lookup through a link is then matched by its vnode. For a name that does not exist yet, the vnode identifies the directory instead. A match then also needs the file names to agree.
• Links near the root: a link such as /var, which points at private/var, makes a path continue from the root. Buildprof checks whether the first name exists in the process's directory or at the root. It checks again every time, because a build creates and deletes directories as it goes.

Links that no process ever looks up by absolute path are still resolved against the process's directory. #49 records those as unknown instead.

Benchmarks

Share of paths that match what Endpoint Security reports for the same build:

Build	Before	After
Clean cargo build	68%	83%
make	64%	92%

With the whole stack, build outputs, crate sources and project files match 99 to 100% of the time. The paths that still differ are reads of toolchain files.

Testing

Unit tests cover recovering a lookup that restarted at a symbolic link, and resolving one that restarted at a link near the root.