Rethink how we approach Date Range Facets

[DiegoPino]

What?

Date range facets are a mess. First we need to actually know the min and max, which also means if we have like 10K different dates, the count must be unlimited to actually get the right values. But also, the way facet/Solr search api is setup requires either an INT (timestamp) for the date to use a native facet.range solr query argument (which is better than what we can do right now) or to write (what I want) our own processor/data type that allows a facet.range to be used with real dates and %YEAR/DATE native solr nomenclature, see https://solr.apache.org/guide/solr/latest/indexing-guide/date-formatting-math.html#date-math

Happens that I found that there is "native" support for actual granularity, but only for numbers. Still very promising bc
https://git.drupalcode.org/project/search_api_solr/-/commit/61bbdb7669ff0ae5a809f1b495da2babc97b5d24

but using the proper config values

https://solarium.readthedocs.io/en/stable/queries/select-query/building-a-select-query/components/facetset-component/facet-range/

Can be used to get native dates, on a e.g Year granularity.. with steps in between (e.g every 10 years) which in turn reduces complete the need of handling 10K results to show all dates ... and we could, if possible have Variable granularity? Like if the current start/end dates are 10 years apart, then the increment can be 1 month ... etc

All this said, this requires a LOT of code... e.g we need to tap into a new "data type" that forces "granularity" to be used via hook_facets_search_api_query_type_mapping_alter()

@alliomeria can we talk about this tomorrow afternoon? Bit tired of dealing with dates tbh

[patdunlavey]

following...