SOLR-17274: allow JSON atomic updates to use multiple modifiers or a modifier like 'set' as a field name if child docs not enabled

[eukaryote]

Fixes problems with the JsonLoader's parsing of atomic update values that use multiple modifiers in a single update or reference a field name that matches a modifier (like set or add).

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

Description

Fixes two problems with JSON atomic updates where an atomic update value like {"set": {"set": "foo"}} (set a field named set to value foo) or {"foo": {"add": "bar", "remove": "baz"}} (add bar value to and remove baz values from field foo) would throw an exception due to isChildDoc thinking a nested doc was being updated. The exact exception message was:

Unable to index docs with children: the schema must include definitions for both a uniqueKey field and the '_root_' field, using the exact same fieldType

Solution

I modified the isChildDoc method of JsonLoader to check if the schema is usable for child docs, and to return false if not. I also had to revert a part of the logic in parseObjectFieldValue so that it would return all the modifier values when there are multiple. The isChildDoc behavior is unchanged if the schema does support child docs, so the same error with continue to be thrown in that case.

Tests

There weren't any atomic update tests that used the JSON loader previously, so I added a new schema file with the minimal fields needed to test this functionality and some tests for existing functionality via Json and for what is changed by this PR.

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

The only tests that failed were the S3 tests, which I believe is common and not necessarily a problem if my changes shouldn't have affected the s3 functionality.

[dsmiley]

Nice test

[dsmiley]

Map.of

[eukaryote]

Map.of doesn't seem to allow null values, so I can't do Map.of("set", null) here. What do you suggest instead of HashMap?

[dsmiley]

ah well; its okay. I hate the syntax hack with the HashMap subclass but I see its appeal in being able to use it inline like this.

[eukaryote]

Oh, it looks like one of the checks is failing because of the instance initializer block, so I'll change it to use HashMap but avoid that.

[eukaryote]

Updated.

[dsmiley]

Thinking of wording for CHANGES.txt:

Improved disambiguation of atomic updates from child docs for JSON based updates (not an issue for other formats).
Multiple atomic updates to a field in one update is supported (again). Schema fields can be named "set", "add", etc. (again). These improvements only apply when the schema doesn't have the root field (no child docs).

[dsmiley]

Alternatively I rather like the title here:

allow JSON atomic updates to use multiple modifiers or a modifier like 'set' as a field name if child docs not enabled

[dsmiley]

I'll merge this tonight unless I hear to the contrary.