Consider reducing ETW events

[rokonec]

During investigation of graph build I have find out that we might be tracing too many ETW events.

I believe that amount of ETW tracing shall be reasonable as extensive ETW logging can cause:

• too big overhead of capturing ETW events, which could skew perf traces
• too big trace files slowing down investigation
• way too big trace files causing perfview capture circular buffer overrun which results in missing events - prohibiting some trace analysis
• all above will result into more difficult/impossible trace capturing of tools integrated with MSBuild - such as Visual Studio

Event Statistics

Name	Count	Average Data Size	Stack Count
Microsoft-Windows-Kernel-File/Create	4,292,940	273	4,292,940
Microsoft-Build/ApplyLazyItemOperations/Stop	3,170,927	32	0
Microsoft-Build/ApplyLazyItemOperations/Start	3,170,924	32	0
Windows Kernel/StackWalk/StackKeyKernel	2,466,245	24	0
Windows Kernel/StackWalk/StackKeyUser	1,841,718	24	0
Windows Kernel/TcpIp/TCPCopy	1,809,001	28	0
Windows Kernel/PerfInfo/Sample	1,383,667	16	1,365,310
Windows Kernel/StackWalk/KeyDelete	1,345,336	299	0
Microsoft-Windows-DotNETRuntime/ClrStack/Walk	1,090,282	446	0
Windows Kernel/DiskIO/ReadInit	784,799	12	784,799
Windows Kernel/DiskIO/Read	784,799	52	0
Microsoft-Windows-DotNETRuntime/ThreadPoolWorkerThread/Wait	776,601	10	0
Windows Kernel/TcpIp/Recv	776,115	28	1
Windows Kernel/DiskIO/WriteInit	689,648	12	689,648
Windows Kernel/DiskIO/Write	689,647	52	0
Microsoft-Windows-DotNETRuntime/GC/AllocationTick	644,655	168	644,639
Microsoft-Build/EvaluateCondition/Stop	608,035	132	0
Microsoft-Build/EvaluateCondition/Start	608,034	128	0
System.Diagnostics.Eventing.FrameworkEventSource/ThreadPoolEnqueueWork	481,685	8	481,685

Based on above we shall reconsider if we need ApplyLazyItemOperations(Start|Stop) and EvaluateCondition(Start|Stop).

Easiest solution would be to have them #IF DEBUG.

Note: In case it is needed to capture at customer equivalent data are captured by Evaluation Profiling

[KalleOlaviNiemitalo]

Could also define a keyword for less voluminous events so that they can be enabled while keeping ApplyLazyItemOperations and EvaluateCondition disabled.