feature: epoch timestamps as a standard

[NDStrahilevitz]

Feature Proposal

Feature will do the following:

1. Simplify normalization logic - only monotonic/boot <-> epoch, remove timeNormalizer object
2. Remove relative-time flag - tracee only outputs epoch timestamps
3. Normalization done asap - ideally at point of event decoding, arguments processed first - new code can and should rely on the assumption of normalized timestamps

Discussed in #4273

^{Originally posted by NDStrahilevitz September 3, 2024}
Hey all.

As I'm working on code related to the event timestamps right now, I was struck by the option that no one is really using the relative time feature. The feature is currently enabled by appending the -o option:relative-time flag to tracee, or setting it in the config file. Once enabled, timestamp values in the event context and arguments are printed relative to the point in time in which tracee's process begun (so instead of ts: epoch_time_at_record -> ts: time_from_boot_at_record - tracee_recorded_starttime_from_boot).

I believe we have the following reasons to remove:

1. No intrinsic advantage over epoch time: relative time does not allow a comparison or timeline assessment of event occurence, especially given a crash/restart in a tracee daemonset. The only intrinsic advantage is a more or less precise duration from tracee's start, but even that can be approximated through the first event or other means on the host.
2. The plurality of timestamp outputs complicates the usage and implementation of ad-hoc analysis in the planned analyze mode (#3520). The two solutions proposed for these are either "marking" the timestamp, such that any operation done on it can rely on the mark + awareness of ad-hoc analysis (which couples it to the notion of time), and/or relying on the tracee_info event which solely exists currently to inform of the state set for tracee in some pipeline work.
3. In contrast, it seems to me that by removing the relative time feature we could simply rely on the any event source converting its timestamps to epoch as standard. There will be no different outputs for events, anyone who wants to convert tracee event times to some "relative from" timestamp can do it on their own, per their requirements. Any addition of custom events will require, by standard, to set epoch timestamps on all relevant fields. This turns the issue of timestamps to an issue of standard compliance, and a compliance which is certainly possible.

Any thoughts? Any who are directly in favor or against?