Add EventPipe EventSource serialization testing

[noahfalk]

We've had EventSource serialization tests for a long time but EventPipe never got added to it. Unforetunately not testing EventPipe in this way previously meant that quite a few discrepancies between EventPipe and ETW went unnoticed. As a first step to documenting and/or resolving the problems I wanted to get EventPipe running in the same set of tests. I also did several other small fixes and improvements while doing the work.

• EventPipeListener added as a new 3rd target for EventSource (in addition to EventListener and ETW which are there now)
• Modified the Listener test abstraction so that EventPipe could also work
  • Removed assumption that providers can changed after the listener starts running
  • Added capability flags to indicate whether listeners supported certain kinds of serialization behavior
  • Worked around incomplete implementation of IDictionary for payloads in TraceEvent
• Leveraged xunit theory attribute to avoid needing different top-level APIs for every listener configuration
• Fixed EventTestHarness assert which had actual and expected values swapped
• TestsWrite: Fixed mistaken call to Array.Equals with Assert.Equal so the test actually validates what it was supposed to
• Removed ActiveIssue 88305 attribute which was already closed in the past.
• Moved some test cases from TestsWriteEvent.Etw.cs to TestsWriteEvent.cs so that they can run for other listeners when supported.

[noahfalk]

fyi @lateralusX

[dotnet-policy-service]

Tagging subscribers to this area: @tarekgh, @tommcdon, @steveisok
See info in area-owners.md if you want to be subscribed.

[mdh1418]

Do we only want to test DynamicConfigChange on particular tests? Or would it be valuable to have both DynamicConfigChange and non DynamicConfigChange for all EventSource tests? Just curious when to test Start -> EventSourceCommand vs EventSourceCommand -> Start like how TestsUserErrors.cs uses the former in Test_BadTypes_Manifest_UserClass but uses the latter in Test_BadEventSource_MismatchedIds.

nit: inconsistency of one-line if blocks using/not-using curly braces + if( -> if (

[noahfalk]

Do we only want to test DynamicConfigChange on particular tests? Or would it be valuable to have both DynamicConfigChange and non DynamicConfigChange for all EventSource tests? Just curious when to test Start -> EventSourceCommand vs EventSourceCommand -> Start

I think there are a few parts to this and I believe they are still getting tested:

1. What is the ordering of enabling the provider in respect to enabling the session. ETW and EventListener are enabling the session first and providers afterwards as they were before. Although the EventSourceCommand() calls occur before Start() the internal queueing means the commands get executed after the session already started.
2. What is the ordering of enabling the provider relative to registering the EventSource - both orderings are tested.
3. What is the ordering of disabling the provider relative to ending the session. The test disables one of the providers early to confirm the events aren't received but this is only done for ETW and EventListener since EventPipe doesn't support the dynamic config change.

[Copilot]

Pull Request Overview

This PR adds EventPipe as a third event listener target alongside the existing EventListener and ETW implementations in the EventSource serialization tests. Previously, EventPipe was not tested through this framework, which allowed serialization discrepancies between EventPipe and ETW to go unnoticed.

Key Changes:

• Added EventPipeListener implementation using DiagnosticsClient
• Refactored test infrastructure to support multiple listener configurations via xunit Theory
• Added capability flags for listener-specific serialization behaviors
• Fixed several existing test issues and removed closed ActiveIssue attributes

Reviewed Changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
System.Diagnostics.Tracing.Tests.csproj	Added EventPipeListener.cs and Microsoft.Diagnostics.NetCore.Client package reference
TestsWriteEventToListener.cs	Added listener.Start() calls to enable proper listener initialization
TestsWriteEvent.cs	Converted individual test methods to Theory-based approach using GetListenerConfigurations(), added conditional test execution based on listener capabilities
TestsWriteEvent.Etw.cs	Updated method signatures and removed ActiveIssue attributes for resolved issue #88305
TestsWrite.cs	Converted to Theory-based tests, fixed Array.Equals/Assert.Equal bug, added listener capability checks
TestsWrite.Etw.cs	Removed ActiveIssue attribute for resolved issue #88305
TestsUserErrors.cs	Added listener.Start() calls for proper initialization
Listeners.cs	Added Start() method, capability flags, pending command queue, and fixed IDictionary iteration bug
EventTestHarness.cs	Updated to use new Start() pattern and fixed swapped Assert.Equal arguments
EventPipeListener.cs	New EventPipeListener implementation for EventPipe event collection
EtwListener.cs	Refactored to support pending command queue and added Start() method
Versions.props	Added MicrosoftDiagnosticsNetCoreClientVersion property

[noahfalk]

/ba-g: Builds are timing out on arm64. This appears to be a problem across many PRs and this PR should have no arm64 specific behavior.

[noahfalk]

@mdh1418 or @lateralusX - can one of you re-approve this? I think something reset the approval.

[noahfalk]

/ba-g this was already green before the rebase. No need to do it again.