CMake project renaming, build improvements, and cleanups

[leogr]

What type of PR is this?

/kind cleanup
/kind feature
/kind documentation

Any specific area of the project related to this PR?

/area build
/area libscap
/area libsinsp

What this PR does / why we need it:

This PR follows up the OSS Libraries Contribution Plan by introducing the following changes:

• rename the cmake project name to falcosecurity-libs
• make the driver name (and some other parameters) configurable via cmake options
• make libscap.patch no longer needed (the patch was required by Falco due to a different naming convention)
• cleanup some old references in the comments

The changes above mainly focus on the build system. Other naming adjustments will be addressed by following PRs.

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Here you can find the testing branch in Falco: https://github.com/falcosecurity/falco/tree/build/apply-libs-pr-41
N.B.: that testing branch is rebased on top of falcosecurity/falco#1671 to address an incompatible change introduced by f7029e2#diff-633539375239ac63e4a9e3358f0852d437b22e9c9f2c96de5e04e346b0b4784fL2074

TODOs:

• rebase
• use scap as default driver name
• use falcosecurity-libs as cmake project name

Does this PR introduce a user-facing change?:

build(userspace/libscap): make probe name configurable, default to `scap`
build: rename CMake project name to `falcosecurity-libs`

[leogr]

/retest

[poiana]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: leogr

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 [leogr]

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

[gnosek]

Honestly, I'd prefer a top-level PRODUCT_NAME (or something) variable that all the variants get generated from. It feels weird to tie fs paths and env var names to the name of a kernel module (that happens to be the string we want)

Do you have a companion sysdig PR?

[leogr]

Honestly, I'd prefer a top-level PRODUCT_NAME (or something) variable that all the variants get generated from. It feels weird to tie fs paths and env var names to the name of a kernel module (that happens to be the string we want)

I intended to make each name configurable (without imposing any prefix/suffix) and using the PROBE_NAME as a fallback to generate defaults when values are not provided.

The env var name is already configurable (except for my mistake, but I will fix it soon).
I can do a similar thing for the fs paths too.

[gnosek]

Any chance you can add a cmake var for the module name (in /sys/modules)? Something like:

string(REPLACE "-" "_" PROBE_MODULE_NAME "${PROBE_NAME}")

(I'm pretty sure I got something wrong, ref: https://cmake.org/cmake/help/latest/command/string.html).

I know it doesn't change anything for falco (which doesn't use the -probe suffix) but it would let OSS Sysdig (and the commercial agent) keep working without risky changes to the prebuilt probes tooling

[leogr]

/retest