The search core and the extension index don't recover when the remote Solr server cannot be reached during startup

Implementation notes and answer to the open point of the description.

• With a remote Solr (solr.type=remote), the search core and the extension index core are still requested when the components using them are initialized, but a failure no longer fails the initialization: it is logged once as a warning, and the core is requested again when needed, at most once every 10 seconds (in between, and while another thread is already requesting the core, the operations fail immediately with the last failure). With the embedded Solr, a core which cannot be loaded still fails the initialization, as before.
• Whether a component keeps the failure for the life of the instance: the components which are looked up lazily retry their initialization at each lookup. That's the case of the indexer, which the indexing listeners get through a provider: the indexing itself recovered once Solr was back, at the cost of a new initialization attempt (and possibly a connection timeout) for each event while Solr could not be reached. Only the listeners registered at startup, and the components injected into them, keep the failure: for the search core that is SolrIndexAvailableLocalesListener. The extension index components recover the same way; the content of the extension index is refreshed by the next run of the extension index job, which runs again after the index interval (one hour by default), not as soon as Solr is back.
• Visible change during an upgrade: the Solr data migrations which use the search core through SolrInstance (R141015000XWIKI20371XWIKI21208DataMigration, R171009000XWIKI24390DataMigration) used to fail to be created when the remote Solr server could not be reached during the startup, and were then skipped (the database version moved past them, so the search core was never cleaned). With this change they are created, fail when executed, and the main wiki is refused ("Migration of database ... has failed") until XWiki is restarted with the Solr server reachable. This is arguably more correct (no silent skip), but an upgrade with a remote Solr server which is not up yet now stops instead of starting with an outdated index. The migrations which inject the Solr component directly keep the previous behaviour until XWIKI-25252 is applied.