Extend property assignment event (The feature is opted-out by default)

[YuliiaKovalova]

Fixes #2711
and connected to KirillOsenkov/MSBuildStructuredLog#839

Context

The feature is opted-out by default due to perf considerations !
This implementation covers cases:

• property coming from a command-line argument (e.g. /p:) (previously had a Global source)
• as an output of a target
• as an output of a task
• exact property location if it comes from xml during evaluation

Also, the message formatting logic was changed for PropertyReassignmentEventArgs, PropertyInitialValueSetEventArgs, UninitializedPropertyReadEventArgs to have it optimized for existing deduplication logic (message is not passed as a part of event).
The event save all the unique data and format it on the receiving side (e.g. LogViewer).

The measurements were taken for the latest OrchardCode

Metric	Before (No Property Logging)	Before (With Property Logging)	After (With Property Logging)
Size	129.720 (unit not specified)	173.779 KB	178.054 KB (please note that now we emit more events!)
Total Opening Time	1:30.515	2:58.457	2:07.049
Loading Time	37.367 s	1:18.232	1:05.392
Analyzing Time	6.080 s	11.716 s	6.962 s
Indexing Time	39.882 s	1:15.502	44.836 s
Reading Files	414 ms	675 ms	786 ms
Memory Allocated	29,386,403,792 bytes	29,372,422,344 bytes	33,422,660,680 bytes
Nodes	176,726,969	168,309,467	168,759,551
Strings Count	339,168	355,202	365,081
Strings Total Size	53,796,282	28,819,213	24,279,588
Strings Largest	79,623	64,035	74,163

[JanKrivanek]

I have couple comments to consider.

The main thing before signoff - this is currently not a default behavior (neither with /bl) - correct? Property tracking needs to be explicitly opted in - right?
Please add that info into the PR description (as otherwise the 8.5% perf hit might be bit concerning and might need a bit more deeper look)

[KirillOsenkov]

How do I enable the feature for testing? What setting value did you use for perf testing?

[KirillOsenkov]

I'm seeing something weird, and it's not because of your PR.

Location for property reassignment is being logged as null, so the property reassignment messages end up looking like this:

But with your PR the location is there:

I don't understand what's going on.

[KirillOsenkov]

There are two things I did to investigate the binlog size increase:

1. use File -> Statistics in the viewer, then right-click on the Statistics node (the last one in the tree) and click Copy children, then diff for an old binlog and new binlog
2. under Statistics -> Strings, expand and select the only node under Strings, then press Space (this will view all the strings in the text editor) - diff those, I notice a lot of new strings with this change (primarily strings for file, line and column appended) - these shouldn't be added

For diffing, pick a simple console application, and do an incremental build (not clean build), setting MsBuildLogPropertyTracking to the right value. What is the default value for it currently? Why are property reassignment messages even logged when the value is 0 (the current default)?

[KirillOsenkov]

Ah, I see:

msbuild/src/Build/Evaluation/PropertyTrackingEvaluatorDataWrapper.cs

Lines 320 to 323 in 4042363

	// Either we want to specifically track property reassignments
	// or we do not want to track nothing - in which case the prop reassignment is enabled by default.
	if ((_settings & PropertyTrackingSetting.PropertyReassignment) == PropertyTrackingSetting.PropertyReassignment ||
	(_settings == 0 && ChangeWaves.AreFeaturesEnabled(ChangeWaves.Wave17_10)))

[KirillOsenkov]

I'm not quite sure, but I think we might have lost the location for property reassignment with #10102 (FYI @JanKrivanek)

[JanKrivanek]

Overall looks good.

Before I'm ready to sign-off I want to be sure that the labeling of property source feels sufficient (e.g. the distionction of globals from scripts) and that the conditions are done as they are meant to be.
Ping me once adjusted or commented here and I'll rereview

[KirillOsenkov]

I think it's mostly in a good shape, I left some minor comments. Since we're not changing the default mainline scenario I'm not worried about perf (which we can always tune in a separate PR).

[KirillOsenkov]

Looks good as far as I can see!

Thanks so much for the perseverance.

[JanKrivanek]

Awesome work!
Very helpful feature!!
Please as well add a mention of the opt-in env var somewhere into our docs