EZP-26807: First implementation for SolrCloud support

[pspanja]

https://jira.ez.no/browse/EZP-26807

This targets Solr search engine v2.0

This implements support for SolrCloud. Support for using Solr in standalone mode is here removed, meaning that from now on Solr search engine will have to be used with Solr backend running in cloud mode.

implicit routing

The approach taken here is using implicit document router to control where the documents are indexed. This is achieved by specifying special field in the indexed document that holds the identifier of the shard it's to be indexed in. In order for that to work the collection must to be created with these parameters:

• router.name=implicit
• router.field=<field name>

Unfortunately implicit routing is not supported by the bundled Solr start script, which can create a collection with compositeId router only, meaning that setting up the cloud for local development will be little bit more involved. Solr initialization script for Travis that is provided here can be used as an example. For more information see:

• DocumentRouting
• Collections API

Previously, running Solr in standalone/multicore mode enabled using a separate schema per core. Usually that would mean a dedicated language analysis would be configured per core. With Solr running in the cloud mode, a collection with all it's shards must have the same configuration. That means we will need to handle multiple (per language) full text fields in the same schema. That is yet to be implemented on this PR. For more details on the available options see Semantic & Multilingual Strategies in Lucene/Solr. For possible future support for dynamic analyzers see SOLR-6492.

compositeId routing

With compositeId routing, exact destination shard for a document is not strictly controlled. With it, we provide the shard key and Solr takes care of choosing the exact shard by itself. For us, that means it would not be possible to direct a document in a specific language to a shard dedicated for that language.

While this might not fit the multilingual setup, it would be desirable for single language setup. The benefit of compositeId routing is that shards can be split, which is not possible when using implicit routing. While theoretical document limit per shard is of no concern for us (more that 2 billion documents), being able to split shards is still practical, as Solr node will work best if it has enough memory to cache it's data.

Implementing support for compositeId routing is left for future improvement.

TODOs

• Update schema and full text search to use multiple full text fields
• Adjust integration tests once Do not call getSubtreeLocationsCount from provider ezpublish-kernel#1871 is fixed

[pspanja]

Now added an issue and some description. Any feedback welcome.

[andrerom]

rebase needed to add 6.4.1

[adamwojs]

Closed in favor #137