Investigate batching / parallelizing trace event processing

[christos68k]

Some time ago we switched trace event processing from batching to single events. This means that we're now processing trace events serially, one-after-another as we read them from the per-CPU buffers: tracer sends each individual trace event to tracehandler over an unbuffered channel while inside the event drain loop.

During recent rework of SymbolizationComplete we noticed that batching (at some extra memory cost) can be trivially introduced: tracer can first drain the per-CPU buffers into an event batch and send that batch to tracehandler.

Additionally, there's the option of having tracehandler process events in that batch in parallel. That would help avoid dropped events in the tracer drain loop (recently introduced metrics should reveal if that is taking place). From a quick glance it seems that most trace processing operations can be trivially parallelized, as they don't depend on a write lock.