Add filtered binary log replay

[YuliiaKovalova]

Summary

• add an opt-in BinLogReader.EventFilter callback with record kind and build event context metadata
• skip rejected event-specific payloads in version 18+ length-framed binlogs while continuing to process auxiliary records
• preserve required culture initialization for modern and legacy binlogs, and fall back to full deserialization for older formats and TargetSkipped records
• propagate filter callback exceptions while always completing the threaded replay worker
• cover compact reserialization, metadata, truncation, culture preambles, worker cleanup, and exception behavior with tests

Motivation

Consumers that need only a subset of a large binary log currently deserialize every event. This API lets them reject records after reading lightweight common metadata, then connect accepted replay events to BinaryLogger to produce a compact, standalone filtered binlog.

Validation

• 6 filtered-replay tests pass
• 98 remaining tests pass when excluding three environment-dependent baseline failures reproduced on unmodified main

[JanKrivanek]

Looks good and helpful. I added couple questions

If BuildEventArgsReader.cs is still in sync with dotnet/msbuild (and it should) - we should reflect the change there as well

[YuliiaKovalova]

@JanKrivanek re: keeping BuildEventArgsReader.cs in sync - the matching change is up as a draft at dotnet/msbuild#14693.

A few things differ there, driven by what msbuild's reader actually has:

• No culture preamble special-casing. ProcessCultureMessage/Strings.Initialize is viewer-only (BuildEventArgsReader.Viewer.cs), so the msbuild port drops that branch.
• SkipBytes left untouched. The change here exists to keep truncation recovery (ReachedEndOfStreamPrematurely) working when a rejected record is skipped; msbuild has no truncation recovery, so Seek stays as-is there.
• Raw passthrough had to be handled. BinaryLogReplayEventSource copies records verbatim when there are no structured subscribers, which would silently bypass the filter - so a set EventFilter now forces structured reading.
• New public API (BinaryLogEventMetadata, BinaryLogEventFilter, BinaryLogEventFilterException, the Read overload, BinaryLogReplayEventSource.EventFilter) plus a localized resource string, hence draft pending API review.

[KirillOsenkov]

I'm guessing there's no perf overhead when no filter is specified? and we don't care much about perf when the filter is specified? would be good to see some numbers for large-ish binlogs.

[KirillOsenkov]

Published in https://www.nuget.org/packages/MSBuild.StructuredLogger/2.3.244

[YuliiaKovalova]

Published in https://www.nuget.org/packages/MSBuild.StructuredLogger/2.3.244

I measured the dotnet/msbuild port (#14693) by replaying binlog: call Replay() => subscribe to AnyEventRaised  -> count events, and wrap the replay in  GC.GetTotalAllocatedBytes(precise: true).

There's a warmup pass first, and a forced GC before every iteration.
Scenarios are interleaved, and I reverse the order every other round so no run gets an advantage from sitting in a warm cache.

1. No filter -> no overhead. 451.7 MB / 21.9 M events:
   ┌────────────────────────┬────────────┐
   │ │ Events │ Allocated bytes
   ├────────────────────────┼────────────┤
   │ baseline │ 21,914,589 │ 23,319,014,776
   │ with change, no filter │ 21,914,589 │ 23,319,022,648 │
   └────────────────────────┴────────────┘
   Counts match exactly. Allocations differ by 7,872 B out of 23.3 GB (0.00003%).

2. With a filter (allocations, same log):

• dropping ProjectEvaluation*  −36%;
• dropping messages/diagnostics −24%;
• keeping only start/finish records + errors + warnings −63%.

more info is here dotnet/msbuild#14693