Add telemetry for settings UI traffic

[carlos-zamora]

Summary of the Pull Request

Adds a telemetry provider to the Terminal.Settings.Editor project as well as new telemetry events to track traffic through the settings UI. Specifically, the following events were added:

• NavigatedToPage: Event emitted when the user navigates to a page in the settings UI
  • Has a PageId parameter that includes the identifier of the page that was navigated to
  • (conditionally added when PageId = page.editColorScheme) SchemeName parameter tracks the name of the color scheme that's being edited
  • conditionally added when PageId = page.extensions:
    • ExtensionPackageCount: The number of extension packages displayed
    • ProfilesModifiedCount: The number of profiles modified by enabled extensions
    • ProfilesAddedCount: The number of profiles added by enabled extensions
    • ColorSchemesAddedCount: The number of color schemes added by enabled extensions
  • conditionally added when PageId = page.extensions.extensionView:
    • FragmentSource: The source of the fragment included in this extension package
    • FragmentCount: The number of fragments included in this extension package
    • Enabled: The enabled status of the extension
  • (conditionally added when PageID = page.newTabMenu) if the page is representing a folder view
  • conditionally added when PageID = page.profile.*:
    • IsProfileDefaults: if the modified profile is the profile.defaults object
    • ProfileGuid: the guid of the profile that was navigated to
    • ProfileSource: the source of the profile that was navigated to
    • conditionally added when PageID = page.profile (aka the base profile page):
      • Orphaned: tracks if the profile was orphaned
      • Hidden: tracks if the profile is hidden
    • (conditionally added when PageID = page.profile.appearance) HasBackgroundImage: if the profile has a background image defined
    • (conditionally added when PageID = page.profile.appearance) HasUnfocusedAppearance: if the profile has an unfocused appearance defined
• AddNewProfile: Event emitted when the user adds a new profile IsExtensionView parameter tracks if the page is representing a view of an extension
  • Has a Type parameter that represents the type of the creation method (i.e. empty profile, duplicate)
• ResetApplicationState: Event emitted when the user resets their application state (via the UI)
• ResetToDefaultSettings: Event emitted when the user resets their settings to their default value (via the UI)
• OpenJson: Event emitted when the user clicks the Open JSON button in the settings UI
  • Has a SettingsTarget parameter that represents the target settings file (i.e. settings.json vs defaults.json)
• CreateUnfocusedAppearance: Event emitted when the user creates an unfocused appearance for a profile
  • IsProfileDefaults: if the modified profile is the profile.defaults object
  • ProfileGuid: the guid of the profile that was navigated to
  • ProfileSource: the source of the profile that was navigated to
• DeleteProfile: Event emitted when the user deletes a profile
  • also includes ProfileGuid, ProfileSource, Orphaned from the NavigatedToPage section above

The page ids can be reused later as a serialized reference to the page. We already use the one for the extensions page for the "new" badge.

[DHowett]

we don't have a DllMain in the settings editor. Where is it supposed to go?

You'll need to add one! Crib init.cpp from TerminalSettingsModel.

[DHowett]

Suggested change

	const auto& currentPkgVM = _ViewModel.CurrentExtensionPackage();
	const auto& currentPkg = currentPkgVM.Package();
	const auto currentPkgVM = _ViewModel.CurrentExtensionPackage();
	const auto currentPkg = currentPkgVM.Package();

[carlos-zamora]

Applied. Curious, why? Since they're both COM objects, wouldn't we want the & to prevent the unnecessary refcount change?

[DHowett]

The & only matters if you're getting a reference from the function you're calling. It is meaningless and misleading otherwise, as it ALWAYS causes a copy (in the case of a projection pointer, a copy is an AddRef) when the function you've called does not return a reference.

[lhecker]

The rules around & for return values are just unnecessarily complex in C++. It makes no sense that you can't just write let x = foo() and x is inferred to be a reference if foo() returns one. The let equivalent is decltype(auto) which is mouthful no one types.

Initially I had the stance (for myself) that we should try to take WinRT objects by reference to avoid copies, but looking at the complexity this results in I've come to conclude that simply copying parameters is simpler. (This doesn't apply to STL objects though, of course, since they're not ref-counted.)