IBX-9845: Upgraded Solr to version 9.8.1

[mikadamczyk]

🎫 Issue	IBX-9845

Related PRs:

• IBX-9845: Added test skipping for Solr doesn't support shard URL core#593

Description:

This PR introduces support for Solr 9.8.1, in addition to maintaining compatibility with Solr 7.7.x and 8.11.x.
The update affects initialization scripts, configuration file selection, and CI workflows, ensuring smooth integration and automated testing for the latest Solr LTS.

• The script .github/init_solr.sh was updated to support Solr 9.8.1, including logic to choose different config files based on the Solr version (Solr 9.x uses managed-schema and new custom-fields-types).
• There are changes to how TEMPLATE_DIR is set up for Solr 9.x (now includes /conf)
• The default SOLR_VERSION is now set to 9.8.1
• In the init_solr.sh, the flag -Dsolr.disable.shardsWhitelist=true is no longer used when starting Solr 9.x. For older versions , it is still used. In older Solr versions, the shards whitelist was a security feature restricting which hosts Solr could communicate with in distributed queries. Setting -Dsolr.disable.shardsWhitelist=true was often necessary in development and CI to allow all URLs. In Solr 9, this setting was replaced by allowUrls in the configuration.
• No Usage of -Dsolr.disable.allowUrls=true. It would globally disable Solr’s allowUrls security (making the server accept any URLs in distributed queries). It's a security anti-pattern for production and is not recommended even for testing, unless absolutely necessary. Instead, the script configures the allowUrls property specifically in the configuration using the ALLOW_URLS environment variable and the generate-solr-config.sh script.
• Changes in MapLocationDistanceRange.php and move to LatLonPointSpatialField. The location field’s fieldType was updated from Solr's legacy spatial type LatLonType to LatLonPointSpatialField in Solr 9.

If Solr version 9 is used I,t is obligatory to set:

ibexa_solr:
    version: '9.8.1'

For QA:

Documentation:

[sonarqubecloud]

Quality Gate failed

Failed conditions
3.4% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[adamwojs]

Why 63510 ?

[mikadamczyk]

To be honest, it comes from the direct conversion of https://github.com/ibexa/solr/pull/95/files#diff-1127a1f6be52315ed65f6d9331bab2c616849de0124f37a619b61043c88f347aR70 . I suppose the literal 63510 there is just a “magic number” fallback for the upper bound of the distance filter. It guarantees that, if the user didn’t supply a maximum distance, we’ll end up filtering out nothing on the high end.
Maybe it could be replaced by 20038, if needed. For example, as a MAX_EARTH_DISTANCE_KM or something.

[sonarqubecloud]

Quality Gate failed

Failed conditions
3.3% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[tomaszszopinski]

QA approved on Ibexa DXP 5.0 exp.