Correctly handle mixed object paths in XContentMapValues

[romseygeek]

When we have an object that looks like this:

{
  "foo" : {
    "cat", "meow"
  },
  "foo.bar" : "baz"

where the inner objects of foo are defined both as json objects and via
dot notation, then XContentMapValues.extractValue() will only descend
through the json object and will not collect values from the dot notated paths.
In these cases, the foo.bar values will not be returned in the fields
section of a search response.

This commit adds the ability to check both paths, ensuring that all relevant
values get returned as part of fields.

Fixes #65499

[elasticmachine]

Pinging @elastic/es-search (Team:Search)

[romseygeek]

I've marked this for 7.11 but we could conceivably backport it to 7.10.1 as well.

[romseygeek]

@elasticmachine update branch

[cbuescher]

I took a look since the case this issue fixes also might be interesting for #65386 and the change here makes sense to me. LGTM, but maybe you want to wait for a second pair of eyes here.

[nik9000]

LGTM

[jtibshirani]

Thanks @romseygeek for fixing this! I noticed there's a related but slightly different edge case:

{
  "foo" : {
    "bar", "meow"
  },
  "foo.bar" : "baz"
}

Surprisingly, we allow documents to specify a field both in structured object and dot notation. When parsing, we index both values as if it were specified as an array.

Your PR fixes the problem for XContentMapValues#extractRawValues -- maybe we could add a quick test for that. I could file a separate issue about field fetching/ XContentMapValues#extractValue, which still doesn't handle this correctly.

[romseygeek]

Your PR fixes the problem for XContentMapValues#extractRawValues -- maybe we could add a quick test for that. I could file a separate issue about field fetching/ XContentMapValues#extractValue, which still doesn't handle this correctly.

I've pushed a test for your second case. extractValue is trickier because it only returns a single value, so let's deal with that in a separate issue.