Implement Categories, Regions, Keywords, and Owners filters as facet filters

[dsuren1]

We need to replace the current select inputs with the new facet approach:

• current configuration:

{
    labelId: 'gnhome.categories',
    placeholderId: 'gnhome.categoriesPlaceholder',
    type: 'select',
    suggestionsRequestKey: 'categories'
},
{
    labelId: 'gnhome.keywords',
    placeholderId: 'gnhome.keywordsPlaceholder',
    type: 'select',
    suggestionsRequestKey: 'keywords'
},
{
    labelId: 'gnhome.regions',
    placeholderId: 'gnhome.regionsPlaceholder',
    type: 'select',
    suggestionsRequestKey: 'regions'
},
{
    labelId: 'gnhome.owners',
    placeholderId: 'gnhome.ownersPlaceholder',
    type: 'select',
    suggestionsRequestKey: 'owners'
},

• expected configuration

{
    type: "select",
    facet: "category"
},
{
    type: "select",
    facet: "keyword"
},
{
    type: "select",
    facet: "place"
},
{
    type: "select",
    facet: "user"
},

Requirements

• Remove code related to suggestionsRequestKey and specific API if used only in the select inputs
• Replace select configuration with the one showed above
• Review the workflow to ensure the label of select filter are updated every time the filter form is opened. This is needed only once per app lifecycle
  • apply a filter from the select input
  • refresh the page
  • open the filter
  • the label should be the correct one with the count on the side. To achieve this we need to verify if the value info of a filter has been stored in the filters global object, if not send a request to get information (probably FiltersForm is the place where to do this check)

[dsuren1]

API fixes reference issue GeoNode/geonode#11259

[dsuren1]

@allyoucanmap @giohappy
We believe it is essential and also nice to have, count = 0 in when facet topic items based on the filter applied. Currently these results are skipped in the api response

Three cases where this is useful

1. User applies a facet filter say filter{regions.code.in}=Africa and the count is 10, followed by a static filter filter{resource_type.in}=document which makes the facet topic count 0, in this case, the topic item info is not returned in the response which makes to guess the count when not present.
2. Following up with the above scenario, the user refreshes the page and open filter form, we wont be able to get the topic item info from the filter to display properly the label and count
3. Having count =0 allows us to show the values in dropdown/accordion panel and also lets us to disable if we want, while maintaining the full topic items, giving user more meaningful data rather than skipping it altogether

Workaround for this can be a bit messy in the client end where we have make two calls one with filter and another without and parse it to add the missing topic item with count=0 along with other topic info

Kindly let me know your thoughts.

Please advice

As part of this issue implementation,
On opening filter form after a page refresh, is it okay to show label and count synced properly, when the filter have result i.e with count > 0, and when not, show the value from filter applied (url) which can sometimes be a number or a value with lowercase with no count. These are already in plan to be addressed as part of #1494 however it needs the 3 cases mentioned above to be addressed. If you are fine, then I can create a PR (pending only code cleanup)

Note: This happens only on filter form open after a page refresh. Counts are properly displayed in other cases, ex: when select dropdown/accordion is opened and selected etc

Filter that has results

Filter that returns no result

[giohappy]

As agreed on the call, the backend will extend the available endpoints to let the client ask to include topics in the response even when their count is 0. This way the client won't need to make guesses or extra requests (any additional request directly done by the backend will be far more efficient).

[etj]

Backend issue GeoNode/geonode#11262