Add instance id to protocol with MTP

[mariam-abdulla]

This pull request introduces the InstanceId property across various classes and serializers in the dotnet-test project. The primary goal is to enhance the identification and tracking of test instances. The most important changes include updates to class definitions, record types, and serializers to incorporate the new InstanceId property.

Introduction of InstanceId Property:

• CliConstants.cs: Added InstanceId constant to the HandshakeMessagePropertyNames class.
• CustomEventArgs.cs: Added InstanceId property to DiscoveredTestEventArgs, TestResultEventArgs, and FileArtifactEventArgs classes. [1] [2]
• DiscoveredTestMessages.cs, FileArtifactMessages.cs, TestResultMessages.cs: Updated record types to include InstanceId. [1] [2] [3]

License Header Updates:

• Updated license headers in multiple files to reflect the .NET Foundation's licensing agreement. [1] [2] [3] [4] [5] [6]

Serializer Updates:

• DiscoveredTestMessagesSerializer.cs, FileArtifactMessagesSerializer.cs, TestResultMessagesSerializer.cs: Updated serializers to handle the new InstanceId property during serialization and deserialization processes. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17]

Object Field ID Updates:

• ObjectFieldIds.cs: Added InstanceId field IDs for DiscoveredTestMessagesFieldsId, TestResultMessagesFieldsId, and FileArtifactMessagesFieldsId. [1] [2] [3]

Relates to #45927

[Copilot]

Pull Request Overview

This PR adds a new InstanceId field to protocol messages for the .NET test infrastructure.

• Updates constants and record definitions in IPC models.
• Modifies both serializers and deserializers to handle InstanceId.
• Updates event arguments, logging, and test application event handling to include InstanceId.

Reviewed Changes

Copilot reviewed 14 out of 15 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/Cli/dotnet/commands/dotnet-test/IPC/ObjectFieldIds.cs	Reassigned field IDs to include InstanceId.
src/Cli/dotnet/commands/dotnet-test/CustomEventArgs.cs	Added InstanceId properties to event args.
src/Cli/dotnet/commands/dotnet-test/IPC/Serializers/FileArtifactMessagesSerializer.cs	Updated payload writing and reading to include InstanceId (note incorrect assignment in deserialization).
src/Cli/dotnet/commands/dotnet-test/IPC/Models/*	Updated records to include InstanceId.
src/Cli/dotnet/commands/dotnet-test/IPC/Serializers/DiscoveredTestMessagesSerializer.cs	Updated to read and write InstanceId in discovered tests payload.
src/Cli/dotnet/commands/dotnet-test/IPC/Models/TestResultMessages.cs and Serializers/TestResultMessagesSerializer.cs	Updated to support InstanceId in test result messages.
src/Cli/dotnet/commands/dotnet-test/TestApplication*.cs	Updated event handling and logging to incorporate InstanceId.
src/Cli/dotnet/commands/dotnet-test/CliConstants.cs	Added new constant for InstanceId.
src/Cli/dotnet/commands/dotnet-test/TestingPlatformCommand.cs and TestApplicationEventHandlers.cs	Removed ExecutionIdReceived event and updated logging for InstanceId.

Files not reviewed (1)

• eng/Versions.props: Language not supported

[KalleOlaviNiemitalo]

It's not clear from the PR description what the InstanceId identifies and what creates it. I guess it's the same InstanceId in https://github.com/microsoft/testfx/blob/66b23c38620c1ad74ce3f42d3555defdd2703177/src/Platform/Microsoft.Testing.Platform/ServerMode/DotnetTest/DotnetTestConnection.cs#L30, i.e., it is generated by Microsoft.Testing.Platform and identifies the process and AppDomain that is running the tests; it is not unique for each test in the process.

[Youssef1313]

@KalleOlaviNiemitalo InstanceId identifies the test host (test app) that we are communicating with. It will play a role in a follow-up PR where we combine the use of ExecutionId/InstanceId/TestNodeUid to fix the behavior with Retry extension. Basically, consider you have a test app where you enable the retry extension, and the test fails on the first run but passes on the second run.

The first run and second run are sharing the same ExecutionId, but are having different InstanceId. We will use this information to understand that the test was retried. So, whenever we get a test result we will check "is it the same ExecutionId and same Uid, but different InstanceId? then that's a retry"