Perf: Update editor configuration only after extensions are registered

[sandy081]

Editor configurations are getting updated very aggressively (atleast 20 times) while the extensions are getting registered. This is consuming atleast 200ms.

	Insiders (0cc0904c56)	joh/pausedEvents 7907361	PR c4bd3f8
builtin extensions	185.6	71 (-114.6ms)	94.5 (-90.2ms)
builtin extensions and 30 more	448.8	148.2 (-300.6ms)	163.8 (-285ms)

Thanks to @jrieken for comparing this change with the current insiders and also with his generic solution.

Please see #138259 for more information and perf numbers.

This changes editor configuration to update only after extensions are registered, therefore configuration is being updated only once by this.

[bpasero]

Why not just registerWorkbenchContribution on the LifecyclePhase.Restored phase rather than waiting for extensions explicitly? If this is about startup, that should be fine. We can also think about introducing another phase signaling that extensions are registered, I am sure we would find more places.

[jrieken]

Why not just registerWorkbenchContribution on the LifecyclePhase.Restored phase rather than waiting for extensions explicitly?

The Restored phase is reached before scanning extensions. The issue is that while registering extension contributions too many configuration changes are fired, esp. from custom editors and notebooks. This PR makes sure that editor-land triggers the event only once

[sandy081]

Main intention of this change is to reduce number of times this editor configuration updates configuration. I do not think LifecyclePhase.Restored is what when after extensions are registered. This editor auto lock configuration is listening to editor registrations and updating config, so the right phase is when extensions are registered. I think we can introduce new LifecyclePhase for extensions registered but is not this what IExtensionService.extensionService.whenInstalledExtensionsRegistered is and the new phase is going to be duplicate right.

[bpasero]

I think we can introduce new LifecyclePhase for extensions registered

👍

but is not this what IExtensionService.extensionService.whenInstalledExtensionsRegistered

Yeah it is the same, but it would not duplicate anything, rather make it super easy for workbench contributions to register to this phase. That was the main intent of having lifecycle phases actually. Of course everyone could await promises but the phases avoid a lot of boilerplate code.