Prevent collected exceptions from being dropped due to null event values

[schmittjoseph]

Summary

We have a bug in our in-proc exception collection event source code that results in malformed event payloads whenever an exception doesn't have an activity id. This results in the event pipeline processing the exceptions to be unable to parse the data and drop exceptions.

Below describes the issue, covering what the in-proc event source code is doing and then our pipeline.

In-proc flow:

• Our in-proc code used nullable strings for ActivityId and ExceptionMessage (side note: ExceptionMessage could never actually be null) when declaring the ExceptionInstance event.
• When either of these had a null value, we'd instantiate a PinnedData with a null value.
• When event source goes to serialize this, it doesn't send anything for this field since it's a 0 length payload.

Event pipeline flow:

• When attempting to parse an ExceptionInstance event, we call traceEvent.GetPayload<string>(ExceptionEvents.ExceptionInstancePayloads.{ExceptionMessage,ActivityId}).
• When the value of this field is null on the in-proc side of things, a 0 length payload was used for the field. However since strings are variable length, TraceEvent needs to calculate the length of the string. This is done by searching for a null terminator in the message payload starting at the field offset.
• No null terminator is sent from our in-proc code when the string is null. This means TraceEvent will read other fields payloads until it finds what it thinks is a null terminator, mangling the offset and often times entering a faulted state.

The fix:

• On first glance it might seem like we want to update our traceEvent.GetPayload call to pass in a nullable string (string?). However upon testing this has no impact on TraceEvent's understanding of the fields. It still treats the field as a non-nullable string and expects a null-terminator. There does not appear to be an affordance for TraceEvent to detect that the string has a null value since it's dynamic length.
• Instead we must send empty strings instead of null values. Luckily all of our code in dotnet-monitor gracefully handles either null or empty strings for an exception's ActivityId so we don't have to update that.

Release Notes Entry

Fixed an issue that could sometimes result in exceptions not being reported in exception history.

[schmittjoseph]

/backport to release/8.0

[github-actions]

Started backporting to release/8.0: https://github.com/dotnet/dotnet-monitor/actions/runs/10800213525