refactor: use absolute include paths

[therealbobo]

What type of PR is this?

/kind cleanup
/kind design
/kind feature

Any specific area of the project related to this PR?

/area libscap
/area libpman
/area libsinsp
/area tests

Does this PR require a change in the driver versions?

What this PR does / why we need it:

This PR proposes to enhance the maintainability of the libs components by updating the include paths for libsinsp, libscap, and driver. The motivation behind this proposal is to improve readability of the code and provide a more explicit and organized structure for including header files.

The proposed patch brings:

• Clarity of Ownership:
  Using a more verbose include path ensures clear identification of the owner of each header file. This helps in understanding the origin and purpose of included headers at a glance avoids any possible ambiguity (e.g. utils.h from libsinsp or utils.h from libscap)

• Streamlined CMake Configuration:
  The proposed include paths will align with a more streamlined CMake configuration. Only a minimal set of directory will be included: the LIBS_DIR (/userspace), the driver directory (/driver), and some dynamically generated directories (such as ${PROJECT_BINARY_DIRECTORY}/driver/src/ where the generated driver_config.h is placed). This minimizes the risk of including unnecessary or conflicting headers. Furthermore, given that the proposed change will touch the cmake setup, probably could be worth adopt a more modern approach replacing the global include_directories with the more granular target_include_directories approach.

Specifically, I propose transitioning from the current convention:

#include "strl.h"
#include "sinsp.h"
#include "sinsp_int.h"
#include "chisel.h"
#include "chisel_api.h"
#include "filter.h"
#include "filterchecks.h"

to a more explicit format:

#include <libscap/strl.h>
#include <libsinsp/sinsp.h>
#include <libsinsp/sinsp_int.h>
#include <chisel/chisel.h>
#include <chisel/chisel_api.h>
#include <libsinsp/filter.h>
#include <libsinsp/filterchecks.h>

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

I understand this can be disruptive for some of the adopters of the Falco libs, so this PR acts as a POC and is totally open to feedback and opinions. Overall, the drive for this is to make the libs a more long-sustainable and high-quality codebase.

To illustrate the viability and benefits of the proposed change, I have implemented a patch in my branch of falco. Please find the link to the branch below:

• https://github.com/therealbobo/falco/tree/cleanup-relative-import-paths

Does this PR introduce a user-facing change?:

cleanup(userspace): libs consumers have to change the include paths.

[FedeDP]

Really big effort! Thanks! I would love to know what folks think about this one!
Summoning @terylt @araujof @Molter73 :)

[FedeDP]

/milestone 0.15.0

[jasondellaluce]

This is amazing @therealbobo . +1 on my end, this is quite a big leap towards making the libs true maintainable libraries.

[Molter73]

Hey folks! Unfortunately I'm on leave and don't have the time to do a full review of the PR. Skimming through it, it looks good, just have a couple questions on a few changes that seem unnecessary from my perspective that could also make it harder on adopters to customize things.

[Andreagit97]

/approve

[poiana]

LGTM label has been added.

Git tree hash: 552dba48d4c37be9e3ba9999b4d2febae86fa3da

[incertum]

/approve

[poiana]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Andreagit97, incertum, therealbobo

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Andreagit97,incertum]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment