Search-time extraction of fields

[jpountz]

There are 3 main use-cases for search-time extraction of fields:

• Ad-hoc queries. If you need to run a one-off query, just run it using a script query.
• Saving space. If you index lots of data where some fields are almost never queried, it might make more sense to not index these fields preemptively and just run a script whenever a query needs them. This will also make indexing cheaper.
• Compatibility in time-based indices. If you have time-based indices and introduce a new field in an index template, existing indices won't have this field. Scripted fields might help give a consistent experience when querying this new field across the index pattern.

To make the experience better with scripted search, we're thinking of implementing the following changes:

• Allow using the same scripts in the script query and sort/aggs, to make ad-hoc queries easier. Allow reusing the same scripts in sorts, aggregations and script queries #48059
• Introduce runtime fields, that would have the same semantics as regular fields, but would compute values dynamically. Facilitate adding new fields to existing indices #48063
• Let users know when they run a query that uses slow features such as runtime fields. As we're making runtime fields transparent, it might not be obvious to users why a query is slow, especially if the user that fires queries and the user that configures mappings are not the same person. Giving feedback with the response would help Kibana give information as to why a query is taking time if it doesn't return by X seconds. Warn users when they run slow queries #48058

[elasticmachine]

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

[javanna]

Closing this in favour of #59332 which covers adding support for runtime fields.