Attempt to prevent crash in TelemetryTraceLogger::InitializeInternal()

[florelis]

We have been getting reports of heap corruption crashes on AppInstaller::Logging::TelemetryTraceLogger::InitializeInternal in calls to the COM API, with a recent spike in number of hits.
This is probably due to trying to initialize the trace logger from two places at the same time , so I'm adding synchronization there.
I was unable to get a repro to confirm this was the issue and test that the change fixed it, so it may not actually do anything. See https://task.ms/38253096

Microsoft Reviewers: Open in CodeFlow

Edit: Changed per @JohnMcPMS suggestion.

• Made m_isSettingEnabled a CopyConstructibleAtomic<bool>
• Changed m_isSettingEnabled default value to false, so that we only set it to true after successfully readin the settings
• Moved m_userProfile to be a static in AnonymizeString(). This function is only called when emitting an event, and that happens only if we finished the initialization, which ensures that the use of the settings when getting the user profile path is safe.

[JohnMcPMS]

Locks here are just reverting back to the deadlock potential that we previously had (when a "magic static" was used to synchronize the global telemetry object initialization). I think we need a design change.

I would suggest making m_isSettingEnabled a CopyConstructibleAtomic<bool> so that multiple initialization attempts are less impactful (last writer wins and the changes are more readily observable).

Then I would move m_userProfile to not be a member of this class. It can either just be resolved every time, or if we want to keep the optimization it can be a static in a standalone function. We obviously don't expect it to change over the life of a single telemetry object now, and I wouldn't expect it to change over the life of a process either (at least not observably). It does end up using settings in retrieving the path (😭), so the static could guard against that (and IsTelemetryEnabled could require that settings be prepared as well).

Finally, a comment somewhere to indicate just how everything here is balanced on a razor's edge in terms of potential deadlocking.