Query for multiple indexes with similar names broken

[thet]

/cc @andbag

When constructing a query with similar named indexes like workspace and workspace_root, the query is broken since: #67

Since workspace_root is available in the request, _root is interpreted as an option for the workspace index. This fails with:

2019-06-29 20:01:29,299 ERROR   [Zope.SiteErrorLog:18][waitress] 1561831289.29896470.5221127312205188 http://localhost:8080/Plone/cases/ad4/@workspace_overview
Traceback (innermost last):
  Module ZPublisher.WSGIPublisher, line 155, in transaction_pubevents
  Module ZPublisher.WSGIPublisher, line 337, in publish_module
  Module ZPublisher.WSGIPublisher, line 255, in publish
  Module ZPublisher.mapply, line 85, in mapply
  Module Products.PDBDebugMode.wsgi_runcall, line 60, in pdb_runcall
  Module plone.rest.service, line 23, in __call__
  Module plone.restapi.services, line 21, in render
  Module bda.empower.api.services.workspace_overview.get, line 46, in reply
  Module bda.empower.api.services.workspace_overview.get, line 32, in __call__
  Module bda.empower.discourse, line 223, in get_all_workspace_roots
  Module Products.CMFPlone.CatalogTool, line 457, in searchResults
  Module Products.ZCatalog.ZCatalog, line 611, in searchResults
  Module Products.ZCatalog.Catalog, line 1091, in searchResults
  Module Products.ZCatalog.Catalog, line 634, in search
  Module Products.ZCatalog.Catalog, line 562, in _search_index
  Module Products.ZCatalog.query, line 93, in __init__
  Module Products.ZCatalog.query, line 126, in set
ValueError: index 'workspace': option 'root' is not valid

This issue is related to: eea/eea.facetednavigation#174

[andbag]

It still has to be decided whether the error handling should be different depending on the definition type of the option (via dict or index id with suffix separated by underscore character).
Where is an official documentation for the syntax with underscore characters? It seems to be outdated and apparently exists only for backward compatibility.

I would be happy to receive your feedback.

[agitator]

Here we have still an open edge case:

Given these two similar indexes

prioritization_lv1
prioritization_lv1_effective

and searching by prioritization_lv1_effective

results in ValueError: index 'prioritization_lv1': option 'effective' is not valid because query tries to interpret the last part as operator.