Correction to resolve the event tag once per exported event #5185 - #5187

Fixes #5185.

Resolves the event tag once per exported event instead of twice.

Where to look

The two call sites on main, both storage_reader.GetEventTagByEventIdentifer:

• plaso/multi_process/output_engine.py:256, in _ExportEvents, used for the event
  filter and only consumed when one is set;
• plaso/multi_process/output_engine.py:371, in _FlushExportBuffer, used for the
  output module.

Both were introduced together in 65fb698, "Removed event tag index #3714 (#4154)",
which replaced EventTagIndex.GetEventTagByIdentifier with
reader.GetEventTagByEventIdentifer at each site. In the removed
plaso/storage/event_tag_index.py a lookup was a dict hit followed by
GetAttributeContainerByIdentifier, and returned None without touching the database
when the storage file had no event tags, so calling it twice was close to free.

Change

The event tag is now resolved in one of two places, depending on whether the event
filter needs it:

• with an event filter, in the read loop, since a filter can match on labels, and
  carried through PsortEventHeap to the flush the same way event_data and
  event_data_stream already are;
• without one, when the export buffer is flushed, after duplicate events have been
  discarded, so deduplicated events no longer resolve a tag at all.

Events released from the time slice buffer are resolved at the point they are
exported, since they do not pass through the read loop.

Output is unchanged in both cases. The second point is a behaviour change in that a
deduplicated event no longer causes a lookup, but such events are never written, so
nothing reaches an output module that did not before.

Effect

Measured against a storage file of 1,296,316 events extracted from a disk image, of
which 1,293,801 are exported and 2,515 are discarded as duplicates. Both versions were
run alternately on the same idle machine, twice each, so that run to run variation is
visible rather than assumed:

That is 342.0 s against 290.4 s on average, or about 15 percent of export, for 1.30
million lookups removed.

The proportion depends on what is being exported. The measurement in the issue, over
134,499 events extracted from /var/log where the event data is cheaper to
deserialise and the lookup is therefore a larger share of the total, came out closer
to 10 percent. The number of lookups removed per exported event is one in either case.

Note that these storage files contain no event tags, so each removed lookup is the
inexpensive path: the filter expression is still built and parsed, but
_GetAttributeContainersWithFilter returns without querying when there are no
containers of that type. On a storage file that has been tagged the removed lookup
also avoids a query and the deserialisation of a container.

Tests

tests/multi_process/output_engine.py passes unmodified. Giving PushEvent an
event_tag=None default keeps existing callers working.

psort.py -o dynamic output is byte identical before and after against
test_data/psort_test.plaso, with no filter, with a filter on timestamp_desc, and
with a filter on tag, the last of which exercises resolving the tag before the
filter is applied.

Full end-to-end suite on Ubuntu 26.04, exit 0.