ROX-30437: resolve host path via inode tracking

[Molter73]

Description

This patch makes it so, at start up, we walk through the configured
paths we have to monitor and add the path to the inode of every file we
find. This first implementation is inherently flawed and meant as a way
to show how it would look once it is fully fleshed out.

Checklist

• Investigated and inspected CI test results
• Updated documentation accordingly

Automated testing

• Added unit tests
• Added integration tests
• Added regression tests

If any of these don't apply, please comment below.

Testing Performed

Added tests will validate events generated on an overlayfs file properly
shows the event on the upper layer and the access to the underlying FS.
They also validate a mounted path on a container resolves to the correct
host path.

While developing these tests, it became painfully obvious getting the
information of the process running inside the container is not
straightforward. Because containers tend to be fairly static, we should
be able to manually create the information statically in the test and
still have everything work correctly. In order to minimize the amount of
changes on existing tests, the default Process constructor now takes
fields directly and there is a from_proc class method that builds a new
Process object from /proc. Additionally, getting the pid of a process in
a container is virtually impossible, so we make the pid check optional.

[Molter73]

This is an alternative implementation to #149. Compared to that implementation, there are a few benefits to this implementation:

• We use simpler code on the kernel side, doing a single copy from the contents of the inode storage map to the event buffer it is accessible.
• We are not limited by the verifier in collecting path components by walking up the dentry list, if we hit the 16 component limit we will completely miss the host path (since the path is constructed from the file to the root).
• We don't need to emit all events to userspace for filtering.

However, there are also some downsides:

• Currently only files that exist when fact starts up are tracked.
• Renaming a file would cause it to keep emitting events with the incorrect host path.
• Similarly, renaming a file to a path that is not monitored will have it still emitting events when it shouldn't.
• We are adding a 4K buffer to every inode that falls in a monitored path, this might not seem like much, but it can add up pretty quickly if we are monitoring large numbers of files.
• If configuration of monitored directories is changed, the inode store is not updated in any way.

IMO, though significant the limitations of this implementation can be improved in subsequent PRs, the current implementation should be enough for our current target of monitoring 4 system files that should never be removed/renamed.