[Lens] Use index pattern field property displayName

[kertal]

Describe the feature:
Index pattern fields offer the property displayName.

kibana/src/plugins/data/common/index_patterns/fields/field.ts

Line 60 in 2178a14

displayName?: string;

This is currently not used in Lens. Once #69908 is implemented, this property is customizable by the user. Note that this property is currently customizing the name given the ui setting shortenDottedString is enabled, like currently in Discover.

kibana/src/plugins/data/common/index_patterns/fields/field.ts

Line 144 in 2178a14

obj.comp('displayName', shortDotsEnable ? shortenDottedString(spec.name) : spec.name);

Describe a specific use case for the feature:
E.g long fieldnames, there are lots of them in beats submitted data, could be customized (given #69908 is done)

[wylieconlon]

@kertal it looks like in the current implementation, displayName is a property of the index pattern service which is not persisted with the saved object. Lens is currently set up to read from the saved object directly. Are you planning on moving displayName to the saved object?

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[kertal]

in my current PoC I called the persisted property label, so there will be a persisted property that's accessible for Lens. Makes sense to adapt after finishing #70039

[wylieconlon]

@kertal that sounds like it would be easy to integrate into Lens, since there would be something in the saved object.

[timroes]

Why are we using the saved object directly in Lens, instead of consuming the instantiated index pattern class? Even with that label being present, ideally we should leave that decision to the index pattern implementation and not need to re-implement that in Lens. The main reason why solutions didn't consume the index pattern service was that it only ran on the frontend (yet) and not on the serverside, but we don't have that requirement for Lens (yet)?

[flash1293]

As discussed offline, it makes more sense to switch to the index pattern service when fixing this instead of using the next internal. I opened a separate issue for this: #73306

Closing this one because the other one should include all necessary information.