Looking up all the components of a role fails when a component of the parent component manager is unregistered at the same time

Steps to reproduce

• Look up all the components of a role with ComponentManager#getInstanceList() or #getInstanceMap() on a component manager which has local components of that role and a parent component manager which also has some (e.g. a namespace component manager and the root one)
• At the same time, unregister one of the components of that role from the parent component manager

Result

The lookup sometimes fails with:

org.xwiki.component.manager.ComponentLookupException: Can't find descriptor for the component with type [...] and hint [...]
	at org.xwiki.component.embed.EmbeddableComponentManager.getInstance(EmbeddableComponentManager.java:323)
	at org.xwiki.component.embed.EmbeddableComponentManager.getInstanceMap(EmbeddableComponentManager.java:405)
	at org.xwiki.component.embed.EmbeddableComponentManager.getInstanceList(EmbeddableComponentManager.java:363)

and no component is returned at all, while only the unregistered one is missing.

Expected

The components still registered are returned, without the one unregistered meanwhile.

Analysis

When there are both local and parent components of the role, EmbeddableComponentManager#getInstanceMap() lists the parent's descriptors (getParent().getComponentDescriptorList()) and then looks up each instance with getParent().getInstance(roleType, hint). It only holds the lock of its own entries, so a component unregistered from the parent between the two calls makes getInstance() throw, and the exception fails the whole lookup. Before XCOMMONS-2507, the parent components were taken from getParent().getInstanceMap(), which doesn't have this window.

Besides, the parent instances don't go through the handling added by XCOMMONS-2600 for the local ones (a failing non mandatory component is logged and skipped instead of failing the whole list).

Seen in the flavor upgrade test Upgrade1210Test (xwiki-platform build master #9047): the upgrade replaced xwiki-platform-livedata-api 12.10.9, so JARTranslationBundleFactoryListener unregistered its translation bundle from the root component manager while a REST request for translations was listing the bundles from the wiki one:

ERROR DefaultTranslationBundleContext - Failed to lookup Bundle components
org.xwiki.component.manager.ComponentLookupException: Can't find descriptor for the component with type [interface org.xwiki.localization.TranslationBundle] and hint [jar:file:.../xwiki-platform-livedata-api-12.10.9.jar]
	at org.xwiki.component.embed.EmbeddableComponentManager.getInstance(EmbeddableComponentManager.java:323)
	at org.xwiki.component.embed.EmbeddableComponentManager.getInstanceMap(EmbeddableComponentManager.java:405)
	at org.xwiki.component.embed.EmbeddableComponentManager.getInstanceList(EmbeddableComponentManager.java:363)
	...
	at org.xwiki.localization.internal.DefaultTranslationBundleContext.initializeCurrentBundles(DefaultTranslationBundleContext.java:90)
	at org.xwiki.localization.internal.DefaultLocalizationManager.getTranslation(DefaultLocalizationManager.java:80)
	at org.xwiki.localization.internal.DefaultTranslationsResource.getTranslations(DefaultTranslationsResource.java:96)

In this case the request got no translation bundle at all, so no key was translated for it. Found while assessing the impact of failing functional tests on ERROR logs again.