defer monitorMatchType support (always use simple matching)

[cpoerschke]

motivation is to reduce the scope and complexity of the initial integration.

defer as opposed to remove i.e. looking at https://lucene.apache.org/core/9_11_0/monitor/org/apache/lucene/monitor/QueryMatch.html documentation there's not only HighlightsMatch (deferred here) but also ExplainingMatch and ScoringMatch (both not yet on the monitorMatchType list)

[kotman12]

motivation is to reduce the scope and complexity of the initial integration.

defer as opposed to remove i.e. looking at https://lucene.apache.org/core/9_11_0/monitor/org/apache/lucene/monitor/QueryMatch.html documentation there's not only HighlightsMatch (deferred here) but also ExplainingMatch and ScoringMatch (both not yet on the monitorMatchType list)

For context, simple matching returns the matching query Id list. Now that we may have removed the parallel matcher (depending on the viability of segment parallelization) there is possibly no benefit to this response type. I kept it around before because it let you get the simple query Id list response without a doc list response object (which was hard to populate asynchronously). But I think the doc list response is the correct approach because users are already familiar with it. It seamlessly integrates with other solr features like column fetching and possibly streaming. Moreover, a simple monitor response always has a numFound=0 which is confusing. This could be documented but it feels like a weird API from the start and now I can't even justify it anymore.

I'm still thinking about how features like highlights or explaining match could fit into this (in a later iteration) ..

[cpoerschke]

oops this should have been put back with 483e46f