Handle ServerNotAvailableException in CollectLinuxCommand process probing

[Copilot]

Summary

Handle exceptions in CollectLinuxCommand process probing to gracefully handle processes that cannot be resolved or connected to.

Builds on #5778 (Juan's simple catch-and-skip fix) by adding structured error reporting and covering an additional failure mode (IOException from mid-response disconnection).

Problem

When collect-linux --probe enumerates all published .NET processes, several exceptions can occur between discovery and probing:

• ServerNotAvailableException — diagnostic socket not found (process exited before connection)
• IOException ("Connection reset by peer") — process exited mid-IPC response (Fix issue in Collect-linux probing where process may have exited between enumeration and usage. #5778's catch (DiagnosticToolException or DiagnosticsClientException) does not cover this)
• UnsupportedCommandException — runtime too old to support GetProcessInfo
• DiagnosticToolException — process exited between GetPublishedProcesses and ResolveProcess

Previously (before #5778), these propagated to the outer catch (Exception), printing a full stack trace to stderr and returning UnknownError. #5778 added a catch-and-skip for DiagnosticToolException and DiagnosticsClientException, but silently drops the processes and doesn't cover IOException.

What this PR adds on top of #5778

1. Structured probe results — UserEventsProbeResult enum (Supported, NotSupported, ConnectionFailed) replaces boolean, enabling distinct handling per outcome
2. "Could not be probed" reporting — instead of silently skipping, processes that fail probing are reported in a dedicated section (console) or as unknown (CSV), so users know these processes existed
3. IOException catch — covers the "Connection reset by peer" scenario observed in CI that Fix issue in Collect-linux probing where process may have exited between enumeration and usage. #5778 misses
4. Single-process graceful handling — --probe -p PID and collect-linux -p PID now handle connection failures with clean error messages instead of stack traces
5. UnsupportedCommandException handling — ancient runtimes that don't support GetProcessInfo are reported as NotSupported instead of crashing
6. Preserved original error messages — argument validation errors (-1 is not a valid process ID, Only one of --name or --process-id, etc.) still propagate with their original specific messages and ArgumentError return code

Behavior

Non-probe mode (dotnet-trace collect-linux -p <pid>):

• Connection failure: [ERROR] Unable to connect to process '<name> (<pid>)'. The process may have exited, or it doesn't have an accessible .NET diagnostic port. → TracingError
• Argument errors: original messages preserved → ArgumentError

Single-process probe mode (dotnet-trace collect-linux --probe -p <pid>):

• Connection failure: Could not probe process '<name> (<pid>)'. The process may have exited, or it doesn't have an accessible .NET diagnostic port. → Ok
• Argument errors: original messages preserved → ArgumentError

Multi-process probe mode (dotnet-trace collect-linux --probe):

• Console output shows ".NET processes that could not be probed" section when applicable
• CSV output includes unknown value for unprobed processes
• Processes that exit during name resolution are silently skipped
• Processes that exit during probing are reported with name in the "could not be probed" section

[Copilot]

Pull request overview

This PR improves dotnet-trace collect-linux resilience by handling process-resolution and diagnostics-connection failures during “process probing” so the command no longer crashes when a target process can’t be resolved or connected to (e.g., exits between enumeration and probing, cross-container endpoint issues).

Changes:

• Replaced boolean “supports” probing with a 4-state probe result (Supported/NotSupported/ProcessNotFound/ConnectionFailed) and updated user-facing output.
• Updated machine-wide probe to track and report “unknown/unprobed” processes and emit unknown in CSV.
• Adjusted functional tests to match new probe behaviors/messages (partially—some existing expectations still appear outdated).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 8 comments.

File	Description
src/Tools/dotnet-trace/CommandLine/Commands/CollectLinuxCommand.cs	Introduces multi-state probing, catches DiagnosticToolException/ServerNotAvailableException, updates probe messaging and CSV output.
src/tests/dotnet-trace/CollectLinuxCommandFunctionalTests.cs	Updates/extends tests for new probe outcomes and adds helpers for the new process identifier/message formatting.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mdh1418]

Could I get another review @noahfalk

[mdh1418]

The IOException that one CI test run exhitbed

System.IO.IOException: Unable to read data from the transport connection: Connection reset by peer.
   ---> System.Net.Sockets.SocketException (104): Connection reset by peer
     at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 count)
     --- End of inner exception stack trace ---
     at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 count)
     at System.IO.Stream.Read(Span`1 buffer)
     at System.Net.Sockets.NetworkStream.Read(Span`1 buffer)
     at System.IO.Stream.ReadAtLeastCore(Span`1 buffer, Int32 minimumBytes, Boolean throwOnEndOfStream)
     at System.IO.BinaryReader.ReadBytes(Int32 count)
     at Microsoft.Diagnostics.NETCore.Client.IpcHeader.Parse(BinaryReader reader) in /__w/1/s/src/Microsoft.Diagnostics.NETCore.Client/DiagnosticsIpc/IpcHeader.cs:line 55
     at Microsoft.Diagnostics.NETCore.Client.IpcMessage.Parse(Stream stream) in /__w/1/s/src/Microsoft.Diagnostics.NETCore.Client/DiagnosticsIpc/IpcMessage.cs:line 117
     at Microsoft.Diagnostics.NETCore.Client.IpcClient.Read(Stream stream) in /__w/1/s/src/Microsoft.Diagnostics.NETCore.Client/DiagnosticsIpc/IpcClient.cs:line 107
     at Microsoft.Diagnostics.NETCore.Client.IpcClient.SendMessageGetContinuation(IpcEndpoint endpoint, IpcMessage message) in /__w/1/s/src/Microsoft.Diagnostics.NETCore.Client/DiagnosticsIpc/IpcClient.cs:line 44
     at Microsoft.Diagnostics.NETCore.Client.DiagnosticsClient.TryGetProcessInfo3() in /__w/1/s/src/Microsoft.Diagnostics.NETCore.Client/DiagnosticsClient/DiagnosticsClient.cs:line 595
     at Microsoft.Diagnostics.NETCore.Client.DiagnosticsClient.GetProcessInfo() in /__w/1/s/src/Microsoft.Diagnostics.NETCore.Client/DiagnosticsClient/DiagnosticsClient.cs:line 539
     at Microsoft.Diagnostics.Tools.Trace.CollectLinuxCommandHandler.ProcessSupportsUserEventsIpcCommand(Int32 pid, String processName, Int32& resolvedPid, String& resolvedName, String& detectedRuntimeVersion) in
  /__w/1/s/src/Tools/dotnet-trace/CommandLine/Commands/CollectLinuxCommand.cs:line 319
     at Microsoft.Diagnostics.Tools.Trace.CollectLinuxCommandHandler.SupportsCollectLinux(CollectLinuxArgs args) in /__w/1/s/src/Tools/dotnet-trace/CommandLine/Commands/CollectLinuxCommand.cs:line 247
     ```