Support external-id and edtf property types for faceted search

[JeroenDeDauw]

Fixes #276

Summary

Faceted search fix: Both external-id and edtf properties use StringValue internally, so
the DataValueTranslator already handles their values. The missing piece was that these datatype IDs
were not included in the match statements of SearchIndexFieldsBuilder and ListFacetQueryBuilder,
causing their facets to be silently ignored. Range facets for EDTF are not yet supported (follow-up).

CI fix: Update CI for MW master compatibility — use OpenSearch 1.3 instead of deprecated
Elasticsearch 7.10, handle removal of tests/phpunit/phpunit.php, download phpunit.xml.template
excluded from tarballs, and stop using removed SpecialPageTestBase. MW master remains experimental
due to upstream deprecation warnings in RevisionStore.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.07%. Comparing base (3e2ef0c) to head (bc19792).

Additional details and impacted files

@@            Coverage Diff            @@
##             master     #281   +/-   ##
=========================================
  Coverage     74.07%   74.07%           
  Complexity      399      399           
=========================================
  Files            47       47           
  Lines          1292     1292           
=========================================
  Hits            957      957           
  Misses          335      335           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[JeroenDeDauw]

@SvenLieber @physikerwelt could you give this a try and see if it works well for you?

[physikerwelt]

@JeroenDeDauw would you expect that we have to recreate the index to test this?

php maintenance/run.php CirrusSearch:UpdateSearchIndexConfig
Inferring index identifier...my_wiki_content_first
Validating number of shards...ok
Validating replica range...is 0-0 but should be 0-2...corrected
Validating shard allocation settings...done
Validating max shards per node...ok
Validating analyzers...cannot correct
<Error, collected 1 message(s) on the way, no value set>
+----------+---------------------------+--------------------------------------+
| error | rawmessage | This script encountered an index dif |
| | | ference that requires that the index |
| | | be
copied, indexed to, and... |
+----------+---------------------------+--------------------------------------+

[physikerwelt]

I didn't want to blow away the search index in production, but in our staging server, the patch worked (after recreating the search index).

[JeroenDeDauw]

@physikerwelt yes, you'll have to rebuild, or wait for values to slowly appear as their indexing is triggered by edits to items.

Thanks for testing. Looks like you verified external-id works. What about EDTF?

[physikerwelt]

Sorry, I did not test that.

[physikerwelt]

The recreation of the index makes testing (in our environment) a bit painful.
Do you think we could relax

php maintenance/run.php CirrusSearch:UpdateSearchIndexConfig 

to

php maintenance/run.php CirrusSearch:UpdateSearchIndexConfig --reindexAndRemoveOk --indexIdentifier now

?

[JeroenDeDauw]

No idea

[gcgbarbosa]

@JeroenDeDauw,

Thanks a lot for adding this functionality.
I've tested the PR.

Both EDTF and External identifier work.

The only issue is, for EDTF, range search does not work.

I assumed this was expected, since you've mentioned in the commit that:

Both external-id and edtf properties use StringValue internally

[JeroenDeDauw]

That's right, the EDTF string are stored. Would it be better to store a numeric timestamp so you can do range searches?

We do that in Wikibase RDF for EDTF values: we turn the EDTF into a standard timestamp, but the downside there is that information and precision are lost. It's especially awkward for ranges. For the RDF can we solved that by exporting both the lower and upper bound of a range.

[physikerwelt]

Maybe the improvement of EDTF can be a seperate issue? When working with BibTeX data, you become used to queries like publicationYear=2000 or publicationYear=2001 or .... You think I should really improve the datamodel, but it works for the time being.

[SvenLieber]

@JeroenDeDauw Thanks for addressing the issue, @gcgbarbosa verified that it works for EDTF and external identifiers. I agree with @physikerwelt , the range query can be another issue if it is not a priority for them. This can then be addressed in the future if it becomes a priority for one of the customers.

[JeroenDeDauw]

A follow-up issue for an EDTF-specific UI that allows range queries seems sensible, yes. Feel free to file it.