Dynamically generate ingest node pipeline processor descriptions

[cjcenizal]

In #94432, a user mentioned how useful processor descriptions would be for the pipelines shipped by Elastic. I've opened elastic/integrations#807 to track the work for doing that work. The target UX we're aiming for is to provide a higher-level description of what each processors is intended to achieve at a glance.

However, @andrewkroh (comment) and @P1llus (comment) each made a similar suggestions that many processors are so simple that we should dynamically generate descriptions of what they're doing. This would save time for package maintainers because they'll only need to add descriptions for the more complex processors, such as grok, script, and dissect. It will also benefit users who are creating their own pipelines because they'll similarly be able to save time.

Examples

The rename processor: "Rename {field} to {target_field}"
The convert processor: "Convert {field} to {type}"

Requirements

1. Processors with empty or missing descriptions should be described by dynamic descriptions.
2. Dynamic descriptions should be presented both for each processor in the tree, and also for the processor that's open in the Editor Processor flyout.

[elasticmachine]

Pinging @elastic/es-ui (Team:Elasticsearch UI)

[cjcenizal]

CC @jamiehynds

[ycombinator]

One consideration might be to have Elasticsearch provide the default descriptions, maybe as part of the GET Pipeline API. This way not just the Ingest Node Editor UI but any other consumers of Ingest pipelines (e.g. Dev Tools > Console, potentially elastic-package) could also benefit and the user would see the same descriptions no matter which tool was used to interact with Ingest pipelines.

[cjcenizal]

Thanks for suggesting this @ycombinator! I had a similar thought when I was creating this issue but ended up backing away from it. My primary concern was that users won't be able to discern between user-authored descriptions and dynamically generated descriptions, potentially confusing people. It seems unexpected for the API to independently define content that is intended for authors to customize.

Some secondary concerns: What if the authors speak a language other than English? ES doesn't localize. How frustrating that would be, to be bombarded with noise that's not in your language, with no way to disable it -- potentially even a hostile UX. What if authors want the description to actually be empty? When reading the JSON, the user has access to all of the details of a processor's behavior, so for "obvious" processors some users might see the descriptions as noise.

In the end, it seemed to me like a more targeted solution in Kibana will allow us to safely bypass these concerns and solve the original problem more quickly.