RequestIds in PostExecutionStart/Stop events are not unique for different call stacks

[jialongcheng]

Bug description

PostExecutionStartEvent and PostExecutionStopEvent both contain a request ID. Users should be able to uniquely identify the events based on the request Id and correlate the start/stop event pairs for processing.

In our performance testing, we found out that sometimes different tasks had same request ID. Here is a snapshot of the events:

These events have the same id but from the call stacks of the Start events, they are clearly not from the same task.

[AArnott]

The requestId comes from calling object.GetHashCode() on a unique object. I believe the default implementation of this method returns something based on its memory address, so that's pretty wild that you found cases where the same address happens to be used for the same type of object but unique instances across time.

I expect we could use an interlocked incrementing integer to ensure uniqueness.

[davkean]

Note, it's an int not a long so it needs to truncate the address, so it could be two addresses. But the chances of that still seem super slim for the same type of object?

[weltkante]

Looking at the code the current PR replaces, when NonConcurrentSynchronizationContext is installed as current SC its post method uses the hash of its SendOrPostCallback - a caller controlled delegate in public API is not guaranteed to be unique, in fact Roslyn will try to cache and reuse it wherever possible. (If its never installed/visible to external code this way its not an issue of course.)