Every cluster member sends the same index updates to a remote Solr server

Corrections and clarifications after review of the proposed fix:

• Lost queued updates (correcting the last paragraph of the description). The index update queues are in memory and DefaultSolrIndexer#dispose() clears them when XWiki stops. Today the other members happen to send the same updates, which hides that loss; with the fix they do not. The index synchronization repairs it only partly: it runs only at startup with solr.synchronizeAtStartup=true, it re-indexes only the documents whose document row has a different version (a lost object, object property or attachment update is never repaired), and a lost object or attachment deletion leaves an orphan row (XWIKI-22949). Draining the queues when XWiki stops is XWIKI-25256.
• Known limitation: waiting for the index covers only the local member. SolrIndexer#waitReady() (used by LinkStore#waitReady(), which the refactoring jobs wait on through LinkIndexingWaitingHelper before querying the back-links) and $services.solr.queueSize only see the queues of the current member. Once a member stops indexing the changes of the others, a rename or move started on member B right after a link was saved on member A can run its back-link query before A has sent that link to Solr, and miss it. The window is the indexing latency of A (short when idle, longer under load). A cluster-wide ready indicator would be a separate improvement.
• Assumption: with remote observation, solr.type=remote means one Solr server shared by all the members. A setup with one remote Solr server per member, or members with different solr.type values, would stop receiving the changes made on the other members. The fix documents this next to solr.type in xwiki.properties. An explicit capability (for example a SolrConfiguration method telling whether the index is shared, defaulting to type == remote and overridable by a property) would make it configurable; the fix keeps the check on the type for now.