Adds transport-only flag to always include indices in the field caps transport response

[piergm]

When calling field_caps with an expression that resolves to 2+ indices we currently return in the field caps response on a per-field basis the index where that particular field was found only if there is a mapping conflict (eg: index1 field foo is text and in index2 field foo is a long).
With the following change we allow internal users of the FieldCaps action to set includeIndices a boolean flag that if set to true will always return the indices array.
This allows FieldCaps internal consumers to understand on which indices a certain field was found.
Let's say we have two indices: "index1" with mapping foo1=keyword and foo2=keyword and "index2" with mapping foo2=keyword.
Then when requesting GET index*/_field_caps?fields=* with includeIndices set to true, the field caps response will be:

...
"foo1": {
            "keyword": {
                ...
                "indices": [
                    "index1"<---------------------- ADDS THIS
                ]
            },
"foo2": {
            "keyword": {
                ...
                "indices": [
                    "index1", "index2"<---------------------- ADDS THIS
                ]
            }
...

Note: With includeIndices==false we keep the current behaviour to return "indices" only if there is a mapping conflict.

[elasticsearchmachine]

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

[elasticsearchmachine]

Hi @piergm, I've created a changelog YAML for you.

[benchaplin]

Cool change :)

[benchaplin]

Doesn't this need to be added to the writeTo method and the StreamInput constructor? I'm a bit confused how the tests are passing.

[smalyshev]

Generally I think one of the two things should happen:

1. It is added to the serializations as you noted above, and we have TransportVersion bumped.
2. It's not serialized and then marked transient and a comment is added as to why we don't need to serialize it.

In this particular case I think we do need to serialize it so (1) should happen.

[idegtiarenko]

Also should it be added to equals/hashCode? And to corresponding createTestInstance/mutateInstance in FieldCapabilitiesRequestTests (I think it should).
If/when the new flag is added to equality check we might also have to serialize it in order to fix AbstractWireSerializingTestCase

[piergm]

Hey!

Doesn't this need to be added to the writeTo method and the StreamInput constructor? I'm a bit confused how the tests are passing.

No need to serialize it since we are already sending the indices information that are currently used only for mapping conflicts.

It's not serialized and then marked transient and a comment is added as to why we don't need to serialize it.

++ on this

[idegtiarenko]

Thanks! This looks good from es|ql client view.