SOLR-17686: Make stageInEnglish protected and non-static

[jeanielamwh]

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

Description

Please provide a short description of the changes you're making with this pull request.

Solution

Please provide a short description of the approach taken to implement your solution.

Tests

Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem.

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, not available for branches on forks living under an organisation)
• I have developed this patch against the main branch.
• I have run ./gradlew check.
• I have added tests for my changes.
• I have added documentation for the Reference Guide

[cpoerschke]

Thinking about how the changes in this PR might be described in solr/CHANGES.txt ...

... so the user with a custom component with a custom distributed stage is still left in a "must have and configure a custom SearchHandler that overrides the stageInEnglish method" scenario ...

... might overriding be supported and yet could the base implementation use something like "CUSTOM_42" for a custom stage with value 42?

And looking at how the stageInEnglish method is called, perhaps

  private static boolean checkLimitsBefore(
      SearchComponent c,
-     String when,
+     Supplier<String> when,
      SolrQueryRequest req,
      SolrQueryResponse resp,
      List<SearchComponent> components) {

could also be considered i.e. for stageInEnglish to be only actually called when a limit is exceeded?

[jeanielamwh]

... might overriding be supported and yet could the base implementation use something like "CUSTOM_42" for a custom stage with value 42?

I like this idea. Otherwise, it seems a bit excessive to me that a user with custom stages must override this method that's used for logging only.

Pushed be8e468 to replace the throw with returning CUSTOM_STAGE_<NUM>. What do you think?

[dsmiley]

If we're going to expose this, I'd like to take the opportunity to reconsider this method name to not include the word "English". stageToString would be better IMO.
Otherwise, LGTM

[dsmiley]

Way too advanced/obscure to waste people's time mentioning in CHANGES.txt IMO.