ebpf: add a new required dependency field.

[NDStrahilevitz]

Initial Checklist

• There is an issue describing the need for this PR.
• Git log contains summary of the change.
• Git log contains motivation and context of the change.

Description (git log)

Marking an event as required will make it so failing to attach it's probe will fail tracee.
Otherwise, tracee will continue to load as usual and simply log the failure.
Now events can be loaded with partial dependencies.

Fixes: #1622

Type of change

New feature (non-breaking change adding functionality).

I've marked event dependencies that I think should be required as such, but I'm not 100% confident that I got it right on the first go. So anyone reviewing should pay extra attention to that :)

In addition, the previously named "essential" events have been marked as required, and a function for handling all initial required events was extracted out of New into initRequiredEvents. There may also be edge cases there to watch for.

How Has This Been Tested?

This hasn't been tested yet. It will be tested on a reported GKE environment where tracee failed to load the VfsWritev event. After testing that magic_write can be loaded there I will report back here.

Final Checklist:

Pick "Bug Fix" or "Feature", delete the other and mark appropriate checks.

• I have made corresponding changes to the documentation.
• My code follows the style guidelines (C and Go) of this project.
• I have performed a self-review of my own code.
• I have commented all functions/methods created explaining what they do.
• I have commented my code, particularly in hard-to-understand areas.
• My changes generate no new warnings.
• I have added tests that prove my fix, or feature, is effective.
• New and existing unit tests pass locally with my changes.
• Any dependent changes have been merged and published before.

Git Log Checklist:

My commits logs have:

• Subject starts with "subsystem|file: description".
• Do not end the subject line with a period.
• Limit the subject line to 50 characters.
• Separate subject from body with a blank line.
• Use the imperative mood in the subject line.
• Wrap the body at 72 characters.
• Use the body to explain what and why instead of how.

[yanivagman]

I think that what should be marked as required or not is the probe, and not the event.
If an event was chosen as a dependency of another event, the meaning is that we must successfully load and attach that event, otherwise, it shouldn't be marked as a dependency.
On the other hand, some probes of an event may be required, while other not. One example is vfs_writev probe for magic_write, and another example is when we will have probes that depend on some bpf features that only exist on newer kernels, we might choose if it is a requirement or not for the event.

[NDStrahilevitz]

I think that what should be marked as required or not is the probe, and not the event. If an event was chosen as a dependency of another event, the meaning is that we must successfully load and attach that event, otherwise, it shouldn't be marked as a dependency. On the other hand, some probes of an event may be required, while other not. One example is vfs_writev probe for magic_write, and another example is when we will have probes that depend on some bpf features that only exist on newer kernels, we might choose if it is a requirement or not for the event.

Agreed, so I'll post here what we discussed offline.
You plan to flatten the probe dependencies away from the event dependencies.
Then this PR (or yours) can introduce a probeDependency struct where we can mark a probes as required instead, so we could have a probe as required for one event and unrequired for another (for example vfs_writev and magic_write).

So this PR will wait on that.

[rafaeldtinoco]

I approved this accidentally. Still needs review.

I approved this accidentally. Still needs review.

[yanivagman]

@NDStrahilevitz this PR needs to be rebased on main as probes are now flatten (like we previously discussed)

[NDStrahilevitz]

I am closing this in favor of the fix i've done in #1791