SOLR-17044: Expose api "version" on SolrRequest objects

[gerlowskija]

https://issues.apache.org/jira/browse/SOLR-17044

Description

SolrJ often needs to know whether a given request is for a v1 or v2 API, but doesn't have an easy way to do so. The best it can do is one of two approximations: either check the path string for "____v2", or do an instanceof V2Request check. Both of these are exceedingly brittle.

Solution

This PR introduces a new request on the SolrRequest class: getApiVersion(). It returns an ApiVersion enum value, which can either be "V1" or "V2". The method has a default implementation on SolrRequest which returns the enum value "V1", overriding this on a number of subclasses that represent v2 requests (V2Request, various generated SolrJ classes, etc.)

As usual with these sort of changes, GenericSolrRequest introduces some complications. There's no great way to determine whether a given GSR represents a v1 or v2 API without resorting to the same brittle string inspection we're trying to avoid. This PR solves this by assuming that 'GenericSolrRequest' instances represent v1 API requests, and adds a trivial 'GenericV2SolrRequest' class to represent v2 requests. (Open to other ways of doing this if folks don't like this approach)

Tests

Existing tests continue to pass.

Checklist

Please review the following and check all that apply:

• I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
• I have created a Jira issue and added the issue ID to my pull request title.
• I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
• I have developed this patch against the main branch.
• I have run ./gradlew check.
• I have added tests for my changes.

[gerlowskija]

PackageToolTest currently fails with this PR, due to some quirky GenericSolrRequest usage in the PackageTool and PackageUtils code. It'd take a bit of untangling, but is do-able to fix.

That said - rather than tweaking but retaining the GenericSolrRequest usage, I wonder if it isn't worth moving this part of the code away from GSR entirely in favor of specific SolrRequest implementations. The package APIs aren't currently covered in SolrJ, which is why this code needed to use GSR historically. But this might be a nice chance to add these APIs to SolrJ and kill "two birds with one stone". It'd be more work, but might be worth biting off.

Will think it through over the weekend. If I decide to add the APIs to SolrJ, I'll do it in a separate PR that blocks this one.

[epugh]

From my perspective, GSR is the wrong way to think about a generic interaction.. It has all the overhead and complexity of our SolrJ apis, but without any of the nice typing, helping you craft a query. And in MANY places I see us instead work around GSR by doing our own JSON get/post etc with a straight up HTTP client. I'd love to see 1) Anywhere GSR is used, ask ourselves why we don't have a proper Java request object? 2) GenericSolrRequest deprecated, and then maybe make it a bit easier to just "Send a darn json query to this arbitrary endpoint"..

[gerlowskija]

Yeah - there's a lot, a lot of GSR usage that's only there because folks want to us an API that isn't covered in SolrJ.

IMO there's still some valid usecases for keeping GSR around, even if only to give users a quick-and-dirty way to hit whatever custom endpoint they add to Solr using a plugin or whatever. But 95% of the uses in Solr today are not that haha.

[epugh]

Yeah - there's a lot, a lot of GSR usage that's only there because folks want to us an API that isn't covered in SolrJ.

IMO there's still some valid usecases for keeping GSR around, even if only to give users a quick-and-dirty way to hit whatever custom endpoint they add to Solr using a plugin or whatever. But 95% of the uses in Solr today are not that haha.

I think that is why I wish we didn't have GSR, and just had a better JSON request approach. Let's just accept that JSON string is okay, and use that...