feat: Include rootfs in the `Exec` event

[vadorovsky]

image field of the Exec event is relative to the root filesystem of the process. That makes it hard to determine the location of the binary if the process is containerized (or, in general, runs inside a mount namespace).

That's where the new rootfs comes with help. It contains the full path to the root filesystem, which in case of containers has format like:

/root/var/lib/docker/btrfs/subvolumes/0991d46b6f686f22f06bddb6948073[...]

Using that information, we can still inspect that container layer even when the process (or even container) are not running anymore.

Pull Request Title

Short introduction explaining the motivation and reasoning behind the pull request.

Implementation (Optional)

Feel free to include design and implementation for external review outside of the code changes.

I have

• [x] run cargo fmt;
• [x] run cargo clippy;
• [x] run cargo testand all tests pass;
• [ ] linked to the originating issue (if applicable).

[vadorovsky]

Closing, as it's impossible to get this approach working with overlayfs.

For the context - mountinfo for a containerized process with overlayfs looks like:

472 56 0:63 / / rw,relatime master:2 - overlay overlay rw,lowerdir=/var/lib/docker/overlay2/l/3MRLGYS5NA7PKDTK6FUTRWXFCF:/var/lib/docker/overlay2/l/7LLSOLZI5NN34QNJJGONRP6GXA,upperdir=/var/lib/docker/overlay2/12579336faf6f63ff7ac959a4b585c45ce105a3f20c934a07b01655967748615/diff,workdir=/var/lib/docker/overlay2/12579336faf6f63ff7ac959a4b585c45ce105a3f20c934a07b01655967748615/work

Which means that if you try to retrieve the "source" of the mount in eBPF, you will get /. The /var/lib/docker/overlay directory is mentioned in options, which are FS-specific and I haven't found any way to extract it on eBPF side.

We need an universal solution. I will try my luck different way.