Wait for solution to be loaded before initializing remote telemetry

[CyrusNajmabadi]

No description provided.

[CyrusNajmabadi]

this was already running in the BG before. i'm just moving it earlier (where we're already on the BG) instead of having to jump back to bg to run this

[CyrusNajmabadi]

Note: if WaitUntilFullyLoadedAsync doesn't work, then the following don't work:

1. code actions
2. designer attributes
3. symbol search (which is also used as part of Add-Using, so that wouldn't work)
4. change signature
5. encapsulte field
6. extract interface
7. extract method
8. rename
9. call hierarchy

And likely much more. If this is not something we can depend on, then we have to fix that now. But having some new thing take a dependency on it doesn't substantively change things.

[CyrusNajmabadi]

@jasonmalinowski @sharwell ptal.

[jasonmalinowski]

Note: if WaitUntilFullyLoadedAsync doesn't work, then the following don't work:

@CyrusNajmabadi It's one of those things that can get broken from time to time, my worry was whether we'd end up with a bunch more broken stuff in that case. And even if it completes "eventually" that can still be after some amount of loading time, when I'd expect other features that might depend on OOP to be usable (like classification).

New approach looks good though!

[jasonmalinowski]

(leaving comment here because I can't do it elsewhere)

I like the "wait until launched" mechanism you're adding for uses like the SolutionChecksumUpdater, since it means that as a generic unrelated piece of code can wait. What I don't get though is why we're not just passing the telemetry settings here when we're creating the process, rather than assuming that other thing is going to run?

[CyrusNajmabadi]

What I don't get though is why we're not just passing the telemetry settings here when we're creating the process

i guess i don't understand. how would we get those telemetry settings? it seems like we need to be told about them. which is when we go and pusha ll fo this to the OOP side.