Handle zero-value types for unavailable fields - ArgMeta

[geyslan]

Close: #4335

1. Explain what the PR does

2f31471 fix(events): setuid16 arg name typo
4737625 fix: handle zero-value types for unavailable fields
41eeb29 chore(go.mod): bump types to latest version

2f31471 fix(events): setuid16 arg name typo

'git log --grep old_old_uid_t' in Linux kernel code didn't return any
results.

4737625 fix: handle zero-value types for unavailable fields

Some event arguments, such as "interpreter_*" from sched_process_exec,
were not being populated because the kernel might not always provide
them. This was causing errors during the gRPC proto conversion, as
the values couldn't be asserted - they were nil.

With this change, ArgMeta now holds the Zero value of the type, ensuring
that assignment is always possible without requiring additional parsing
in the pipeline.

This also might help parsing since the Zero field will always have
value, making it easier to assert its type instead of checking for
Name field (string).

2. Explain how to test it

3. Other comments

[geyslan]

@trvll do you mind testing?

[NDStrahilevitz]

I'll review this thoroughly tomorrow.
From a quick glance I have these to say:

1. We should use the effort of type conversion here and already move to hardcoded ArgType enums. These should be used instead of the strings. (We can then add a timestamp argument type and have it autonormalized in the decode stage as I've hinted at in register normalizeTimeArg processor only when proctree is on #4332 (comment))
2. I believe we're handling this issue or a similar one through the argument helper here: https://github.com/aquasecurity/tracee/blob/main/signatures/helpers/arguments_helpers.go#L35. What is the difference in issue? I think further elaboration in the resolved issue would have helped clear the difference.

[geyslan]

I believe we're handling this issue or a similar one through the argument helper here: https://github.com/aquasecurity/tracee/blob/main/signatures/helpers/arguments_helpers.go#L35.

I don't believe so, GetTraceeArgumentByName only checks for nil and errs. We don't want to err in the consumer end since the event is fine.

What is the difference in issue? I think further elaboration in the resolved issue would have helped clear the difference.

The Arg transmitted via grpc arrives lacking the Type since it's nil, then an incomplete Event Arg. When that end tries to convert it back to an event, it fails. Take a look at #4335.

This assures that when an arg field not filled (whatever reason), it sets it with the correspondent zero value.

We should use the effort of type conversion here and already move to hardcoded ArgType enums.

I believe we should indeed, in a chore PR, since it will require to change types and the whole core events fields.

[NDStrahilevitz]

LGTM. Just please add the comment documentation i've requested.

[geyslan]

/fast-forward