ROX-33216: implement inode tracking for path_rename

[Molter73]

Description

This is a first attempt at adding inode tracking to the path_rename LSM hook. A number of changes were needed in order to cover all the possible edge cases in this operation.

The most important change is that inodes are now always sent to userspace alongside with a value that indicates how the event is triggered (by matching an inode or a path), this was needed because the path_rename operation will use an inode number of 0 the same we were doing when the new path is not populated (i.e there is no file on the path we are landing). As a side effect of this, inodes on the kernel side cannot be NULL, some additional cleanup might be needed.

Properly tracking rename operations requires collaboration between kernelspace and userspace, particularly when renaming a directory. In this case, the LSM hook will trigger once and we have no way of iterating through subdirectories and files contained in the directories involved, so the kernel does its best effort with the available information and leaves the heavy lifting to userspace. Where possible, userspace will use the available information in memory to adjust the paths being tracked, any discrepancies will be sorted by (hopefully) subsequent events or a periodic scan of the host. The logic on both sides is documented as thoroughly as possible.

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

Manually tested and added multiple integration tests.