Initialize Stack Allocated Data Structures in TraceLogging

[brianrob]

TraceLogging was broken by #13728 because data structures allocated with stackalloc within code in System.Private.CoreLib are no longer zero-initialized.

TraceLogging ETW tests are not currently enabled and thus, there was no test coverage for this case. I found this break while working to enable the TraceLogging ETW tests.

[jkotas]

Thanks for fixing it!

[stephentoub]

I see that EventData is three fields:

coreclr/src/mscorlib/shared/System/Diagnostics/Tracing/EventSource.cs

Lines 1076 to 1080 in 9c84d12

	internal ulong m_Ptr;
	internal int m_Size;
	#pragma warning disable 0649
	internal int m_Reserved; // Used to pad the size to match the Win32 API
	#pragma warning restore 0649

and in pretty much all of our other providers, we set only DataPointer and Size, and don't zero-init Reserved. I don't know if the native implementation relies on those being zero. Do we need to go through our other EventSources and zero-out as well?

[brianrob]

@stephentoub TraceLogging actually uses Reserved and so I believe that is the cause of this break. From what I can see manifest-based ETW does not and so that's likely why manifest-based EventSources are unaffected. We could do this, but I'm not sure that we need to as requiring this would likely be a significant breaking change on the ETW native APIs. @vancem, do you know if Reserved must be zero'd?

[vancem]

@brianrob. While I could well believe that old ETW code does nothing with the 'Reserved' field, but it really needs to be set to 0 by the clients (that is us) for there to be ANY chance of a Reserved field serving its purpose (which is to allow additional information to be passed in later versions). If clients put trash in there we can never distinguish between trash and a legitimate new use for that field.

Thus I would consider it a bug if we did not initialize Reserved to 0.

[brianrob]

Ok, thanks @vancem. I will address this in a subsequent PR.