PluginIndexes.Unindex.query_index seems to be overly complex and should be refactored

[d-maurer]

• Its docstring is misleading
• There is duplicate code for cache and not_param handling
• Why is caching handled differently for operator "or" and not "or" (likely "and"). We could either cache in both cases a "setlist" or in both cases a set (with in the "and" case the intersection of the current "setlist"s).
  Do we need this caching at all? How often do we have the same index query (with identical parameters) in the same request?

I propose the following new structure:

• we determine the cache key and obtain a cached result: either None or a sequence of sets
• if the cache has no result, we determine from record a sequence of keys to be looked up; for "and", the intermediate result is the sequence of looked up document sets, ordered by len (note that determining the size of an IITreeSet loads all buckets from the ZODB; if this requires real storage accesses, then this length determination can even be more expensive than performing the intersection directly); for "or", the result is the one element sequence of the "multiunion" of the looked up document sets. Cache the intermediate result
• Intersect with resultset and return the final result