SOLR-17279: consolidate security.json constants in tests

[rseitz]

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

Description

The PR creates a SecurityJson utility class that holds a standard "security.json" configuration for use by tests that enable security. Various tests were declaring the same copy/pasted SECURITY_JSON constant, resulting in code duplication; this PR updates those tests to use the new SecurityJson.SIMPLE constant. This is a refactoring PR that only affects test code and does not change any test logic.

Solution

N/A

Tests

No new tests added; got a successful ./gradlew check

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.
• I have added documentation for the Reference Guide

[rseitz]

Tagging @epugh

[epugh]

Lovely refactor! I like how the list of params now formats nicer, and so much less boiler plate.

The one thing is I was debating is the name SecurityJson.. Just looking at it's package and the the file name, it isn't clear that this is a test harness or test util.. SecurityJson makes me think it's a class that models interacting with security.json as a file... I know it's bike shedding, but any other names? Maybe see if we have any similar type of test constant .java class to provide inspiration?

[rseitz]

@epugh About the name, I started with SecurityUtils but it seemed to suggest a more general purpose than the intent of this class, and there are zookeeper and eclipse classes with that same name. Some other ideas that come to mind are SampleSecurityJson, SecurityJsonTestUtils, SecurityJsonUtils, SecurityJsonConstants, SecurityConstants, SecurityTestConstants and so on. Some of those would mean a longer name for the actual string constant containing the json, for example, if we go with SecurityConstants as the class name, we'd need something like SecurityConstants.SIMPLE_SECURITY_JSON

I figured that SecurityJson.SIMPLE was the most concise and someone could further understand the intent by seeing "util" in the package name and seeing that it's in the "test-framework" tree. If I had to pick one of the other options, I think I'd pick SecurityJsonConstants. Let me know if you have a preference or any other suggestions. Thanks for the review!

[epugh]

i think I am coming around to the name...

rethought it!