Suppress Preference Events until Preference Service Ready

[colin-grant-work]

At the moment, we emit many preference events when we first read preference files. That leads to a massive spam of preference events and preference schema change events on startup, even though it seems strange to say that preferences have changed when in fact they're just being read for the first time. In part, we emit those events because we currently only read the files after the PreferenceService declares itself ready. There's some code in the pipeline that would read files before declaring the service ready, and it is probably desirable to delay emitting events until the service is ready. Then the flow would look like this:

Initialize preference providers, read files, establish initial state (no events)
--> Resolve the ready promise
    --> Any changes from the initial state cause an event to be emitted

Feature Description:

To make that model work, we would need to make sure that the following are in place:

• all framework-internal code correctly waits for the providers / services to declare themselves ready.
• it's clear at compile time that you should not try to use the events / values returned by those services before they're ready.
• AND / OR the services behave in a way that responds well to premature use.

The last point is challenging, since most preference retrieval is expected to be synchronous, so we don't have a convenient mechanism for delaying responses.

See some details at

• this issue
• this issue
• this discussion