refactor(userspace/libsinsp)!: file descriptor tables for better OOP design and extensibility

[jasondellaluce]

What type of PR is this?

/kind cleanup

/kind design

Any specific area of the project related to this PR?

/area libsinsp

Does this PR require a change in the driver versions?

What this PR does / why we need it:

This PR attempts refactoring the data structures related to file descriptor tables on the following points:

• Most methods on fd infos could be const or inlined by currently aren't. Furthermore, some methods are currently unused and are now cleaned up
• The sinsp_fdinfo class has fields and methods definitions mixed with no clarity about their order and visibility (what's public and what's not?). The class has been cleanup up with reasonable ordering
• sinsp_fdinfo is currently a template for no good reason, if not the possibility of extending the class with a "sidecar" delegated object. This suboptimal for type safety and pollutes our headers for very little value, whereas the same can simply be attained through inheritance following well-known OOP principles. This also caused defining the type twice (as sinsp_fdinfo_t too), of which unification led to most of the LOC changes of this PR
• The file descriptor tables are currently accessed in their internals from many parts, mostly just with the purpose of looping through their elements, even though we have functional accessors for that. We now uniform that for accessing fds only through loop API
• File descriptor infos are allocated by value instead that by pointer (e.g. which we instead do for thread infos), effectively preventing practitioners and non-falco clients from extending the fd infos, and making allocation a bit puzzling in certain situations. For example, shifting to a pointer-based allocation uncovered a subtle issue in caching fd table queries but that used to work "by mistake"
• Unlike thread infos, there was no factory method for building thread infos, and allocation of new ones was scattered in many points. This is a first step that will allow exposing those tables in the state API accessible by plugins in the future
• Fd infos have been passed as raw pointers without no criteria about who's the memory owner. For example, the simple add_fd path drove me crazy in some paths understanding who owned memory. I've now switched to unique pointers wherever possible. More will come later, but this is a starter.

Which issue(s) this PR fixes:

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

refactor(userspace/libsinsp)!: file descriptor tables for better OOP design and extensibility

[FedeDP]

/milestone 0.15.0

[FedeDP]

/approve

[poiana]

LGTM label has been added.

Git tree hash: 000ed22edf971fe94b811bc409ec385812882a10

[poiana]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: FedeDP, gnosek, jasondellaluce

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 [FedeDP,gnosek,jasondellaluce]

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