Create a date query type

Blimey, so out of date that the namespace in the plugin file is still facetapi rather than facets!

Looking at rerolling this.

Here's my work in progress.

It's working for me, but there are a few bits that aren't finished, because I don't understand the architecture involved:

- this currently needs LinksWidget::getQueryType() to be hacked so it returns the first item in $query_types rather than $query_types['string'], as for the date facet that isn't set! I don't understand what this is meant to be doing here -- can widgets only work with one query type?
- the earlier patch was getting config for the date granularity from the facet config. This is the same problem really: what would provide that UI? Are widgets per-query type?
- I've not refactored to use any code from FacetsDateHandler yet -- I figured I'd focus on getting it working first!
- I can't figure out why sometimes when I filter by a month I get the '(-)' next to the name of the month in the facet, and sometimes I don't!

Thanks for the review!

> Yes, for dates we would like to provide a seperate widget, see #2601302: Date widget: Date range - that is also a very old issue.

I can see that a date range widget would be useful, and specific to dates, but what I'm confused about is it you want a select list, or checkboxes that work similarly to the existing widgets.

Refactored, with added basic widget, and work to general granularity/range (cf: #2627630: Provide a slider widget in Facets module and #2601302: Date widget: Date range)

There's an extended abstract class for executing queries with values in a range - this may or may not be useful for the slider case, it probably needs more data passed to the helper methods?

Implementation of this as a Granularity query class retrieves the value for the steps from the widget configuration. Should add a simple widget implementation for integers (1 - 10, 11 - 20...)

The date extension uses Y m d H i s logic instead of an integer for the granularity.

OK checking a bit more work.

Adds relative date formatting (ago/hence):
Nick_vh mentioned this as desired functionality. I was rather hoping to inject DateFormatter and use that, but there was no control over start/end periods, so it's a full load of string concatenation to make the displayed text living in the query class. This because the Result object must be built there.

Adds some tests:
Note the reflection and mock is almost deliberately obtuse. The point being the query doesn't really need a widget, but that is where the bit of configuration it needs lives.
The SearchApiDateTest has to be based on KernelTestBase because DrupalDateTime also needs a live container which means it's actually there in that test.
There are no tests, yet, for the relative date formatting. This needs either copying the code into the test to work out the relative string for the REQUEST_TIME, or fixing the REQUEST_TIME. There's a patch for core that makes all this make sense #2717207: Add a time service to provide consistent interaction with time()/microtime() and superglobals probably worth testing for this case.

Adds a basic granular widget:
The default display text still needs to be changed. It should be $start - $end, at the moment it's just $start.

I checked over the latest patch which works but I was still getting warnings:

Warning: Invalid argument supplied for foreach() in Drupal\Component\Utility\NestedArray::mergeDeepArray() (line 327 of core/lib/Drupal/Component/Utility/NestedArray.php).

I fixed up the warning by aligning the defaultConfiguration method to how other widgets are structured.

Seems tests are broken but is unrelated to my slight fix.

This patch fix the Exception The created date does not match the input value. when the Granularity is Year or Month.

This is working for me.

I just reported in https://www.drupal.org/node/2802571 that the facet block visibility settings do not allow you to set a "any value in X facet", so the user story of drilling down into date granularity, from Year to Month to Date, is not yet possible, which i believe worked pretty well in d7.

I have tested this issue and I can confirm that it works as expected.

There is a UX issue which I have reported here: https://www.drupal.org/node/2809223

1. +++ b/src/Plugin/facets/facet_source/SearchApiBaseFacetSource.php
   @@ -128,14 +128,15 @@ public function getQueryTypesForDataType(BackendInterface $backend, $data_type_p
   +        $query_types['date'] = 'search_api_date';
   +      case 'boolean':
   

   A boolean can never have the search_api_granular. I would rewrite this function to default to search_api_string and for specific types we should return the specific query types.

2. +++ b/src/Plugin/facets/query_type/SearchApiGranular.php
   @@ -0,0 +1,52 @@
   +      'display' => $value - $value % $this->getGranularity(),
   

   Is there any mathematical ordering defined? What will be computed first? Can this change over time with different PHP versions?

Attaching updated patch that applies to latest 8.x-1.x-dev - to be clear, this does not address Nick's feedback.

@acrollet Please add a interdiff.

Patch #27 works ok for me :).

What if we want to use the date query type but display the facet using the Array widget? (for REST responses) as I can see now, there should be a new Widget for that, or maybe there should be an option in the Date Widget setting form to display it as a list of links or as a plain array.

Attached is patch which implements the first approach, also the interdiff between #20 and #27, there are just two line updated.

Thanks.

+++ b/src/QueryType/QueryTypeRangeBase.php
@@ -0,0 +1,107 @@
+        if ($result['count'] || $query_operator == 'OR') {

$query_operator 'OR' should be lowercase.

No, only #39