[DOCS] Add docs for runtime fields (#62653)

* First steps in docs for runtime fields.

* Adding new page for runtime fields.

* Adding page for runtime fields.

* Adding more to the runtime fields topic.

* Adding parameters and retrieval options for runtime fields.

* Adding TESTSETUP for index creation.

* Incorporating review feedback.

* Incorporating reviewer feedback.

* Adding examples for runtime fields.

* Adding more context and simplifying the example.

* Changing timestamp to @timestamp throughout.

* Removing duplicate @timestamp field.

* Expanding example to hopefully fix CI builds.

* Adding skip test for result.

* Adding missing callout.

* Adding TESTRESPONSEs, which are currently broken.

* Fixing TESTRESPONSEs.

* Incorporating review feedback.

* Several clarifications, better test cases, and other changes.

* Adding missing callout in example.

* Adding substitutions to TESTRESPONSE for shorter results shown.

* Shuffling some information and adding link to script-fields.

* Fixing typo.

* Updates for API redesign -- will break builds.

* Updating examples and including info about overriding fields.

* Updating examples.

* Adding info for using runtime fields in the search request.

* Adding that queries against runtime fields are expensive.

* Incorporating feedback from reviewers.

* Minor changes from reviews.

* Adding alias for test case.

* Adding aliases to PUT example.

* Fixing test cases, for real this time.

* Updating use cases and introducing overlay throughout.

* Edits, adding 'shadowing', and explaining shadowing better.

* Streamlining tests and other changes.

* Fix formatting in example for test.

* Apply suggestions from code review

* Incorporating reviewer feedback 7 Dec

* Shifting structure of mapping page to fix cross links.

* Revisions for shadowing, overview, and other sections.

* Removing dot notation section and incorporating review changes.

* Adding updated example for shadowing.

* Streamlining shadowing example and TESTRESPONSEs.

docs/reference/mapping.asciidoc

@@ -13,7 +13,7 @@ are stored and indexed. For instance, use mappings to define:
 * custom rules to control the mapping for
   <<dynamic-mapping,dynamically added fields>>.
 
-A mapping definition has:
+A mapping definition includes metadata fields and fields:
 
 <<mapping-fields,Metadata fields>>::
 
@@ -30,68 +30,34 @@ document. Each field has its own <<mapping-types, data type>>.
 NOTE: Before 7.0.0, the 'mappings' definition used to include a type name.
 For more details, please see <<removal-of-types>>.
 
-[[mapping-limit-settings]]
 [discrete]
-=== Settings to prevent mappings explosion
-
-Defining too many fields in an index can lead to a
-mapping explosion, which can cause out of memory errors and difficult
-situations to recover from.
+[[mapping-limit-settings]]
+== Settings to prevent mapping explosion
+Defining too many fields in an index can lead to a mapping explosion, which can
+cause out of memory errors and difficult situations to recover from.
 
 Consider a situation where every new document inserted
 introduces new fields, such as with <<dynamic-mapping,dynamic mapping>>.
 Each new field is added to the index mapping, which can become a
 problem as the mapping grows.
 
-Use the following settings to limit the number of field mappings (created manually or dynamically) and prevent documents from causing a mapping explosion:
-
-`index.mapping.total_fields.limit`::
-    The maximum number of fields in an index. Field and object mappings, as well as
-    field aliases count towards this limit. The default value is `1000`.
-+
-[IMPORTANT]
-====
-The limit is in place to prevent mappings and searches from becoming too
-large. Higher values can lead to performance degradations and memory issues,
-especially in clusters with a high load or few resources.
-
-If you increase this setting, we recommend you also increase the
-<<search-settings,`indices.query.bool.max_clause_count`>> setting, which
-limits the maximum number of <<query-dsl-bool-query,boolean clauses>> in a query.
-====
-+
-[TIP]
-====
-If your field mappings contain a large, arbitrary set of keys, consider using the <<flattened,flattened>> data type.
-====
-
-`index.mapping.depth.limit`::
-    The maximum depth for a field, which is measured as the number of inner
-    objects. For instance, if all fields are defined at the root object level,
-    then the depth is `1`. If there is one object mapping, then the depth is
-    `2`, etc. Default is `20`.
-
-// tag::nested-fields-limit[]
-`index.mapping.nested_fields.limit`::
-    The maximum number of distinct `nested` mappings in an index. The `nested` type should only be used in special cases, when arrays of objects need to be queried independently of each other. To safeguard against poorly designed mappings, this setting
-    limits the number of unique `nested` types per index. Default is `50`.
-// end::nested-fields-limit[]
-
-// tag::nested-objects-limit[]
-`index.mapping.nested_objects.limit`::
-    The maximum number of nested JSON objects that a single document can contain across all
-    `nested` types. This limit helps to prevent out of memory errors when a document contains too many nested
-    objects. Default is `10000`.
-// end::nested-objects-limit[]
-
-`index.mapping.field_name_length.limit`::
-    Setting for the maximum length of a field name. This setting isn't really something that addresses
-    mappings explosion but might still be useful if you want to limit the field length.
-    It usually shouldn't be necessary to set this setting. The default is okay
-    unless a user starts to add a huge number of fields with really long names. Default is
-    `Long.MAX_VALUE` (no limit).
+Use the <<mapping-settings-limit,mapping limit settings>> to limit the number
+of field mappings (created manually or dynamically) and prevent documents from
+causing a mapping explosion.
+
+[discrete]
+[[runtime-fields]]
+== Runtime fields
+Typically, you index data into {es} to promote faster search. However, indexing
+can be slow and requires more disk space, and you have to reindex your data to
+add fields to existing documents.
+
+<<runtime,Runtime fields>> are not indexed, which saves disk space and makes
+data ingest faster. You can add runtime fields to existing documents without
+reindexing your data and calculate field values dynamically at search time.
 
 [discrete]
+[[dynamic-mapping-intro]]
 == Dynamic mapping
 
 Fields and mapping types do not need to be defined before being used. Thanks
@@ -114,7 +80,7 @@ You can create field mappings when you <<create-mapping,create an index>> and
 
 [discrete]
 [[create-mapping]]
-== Create an index with an explicit mapping
+=== Create an index with an explicit mapping
 
 You can use the <<indices-create-index,create index>> API to create a new index
 with an explicit mapping.
@@ -255,8 +221,12 @@ The API returns the following response:
 
 include::mapping/removal_of_types.asciidoc[]
 
+include::mapping/mapping-settings-limit.asciidoc[]
+
 include::mapping/types.asciidoc[]
 
+include::mapping/runtime.asciidoc[]
+
 include::mapping/fields.asciidoc[]
 
 include::mapping/params.asciidoc[]

docs/reference/mapping/mapping-settings-limit.asciidoc

@@ -0,0 +1,49 @@
+[[mapping-settings-limit]]
+== Mapping limit settings
+Use the following settings to limit the number of field mappings (created manually or dynamically) and prevent documents from causing a mapping explosion:
+
+`index.mapping.total_fields.limit`::
+    The maximum number of fields in an index. Field and object mappings, as well as
+    field aliases count towards this limit. The default value is `1000`.
++
+[IMPORTANT]
+====
+The limit is in place to prevent mappings and searches from becoming too
+large. Higher values can lead to performance degradations and memory issues,
+especially in clusters with a high load or few resources.
+
+If you increase this setting, we recommend you also increase the
+<<search-settings,`indices.query.bool.max_clause_count`>> setting, which
+limits the maximum number of <<query-dsl-bool-query,boolean clauses>> in a query.
+====
++
+[TIP]
+====
+If your field mappings contain a large, arbitrary set of keys, consider using the <<flattened,flattened>> data type.
+====
+
+`index.mapping.depth.limit`::
+    The maximum depth for a field, which is measured as the number of inner
+    objects. For instance, if all fields are defined at the root object level,
+    then the depth is `1`. If there is one object mapping, then the depth is
+    `2`, etc. Default is `20`.
+
+// tag::nested-fields-limit[]
+`index.mapping.nested_fields.limit`::
+    The maximum number of distinct `nested` mappings in an index. The `nested` type should only be used in special cases, when arrays of objects need to be queried independently of each other. To safeguard against poorly designed mappings, this setting
+    limits the number of unique `nested` types per index. Default is `50`.
+// end::nested-fields-limit[]
+
+// tag::nested-objects-limit[]
+`index.mapping.nested_objects.limit`::
+    The maximum number of nested JSON objects that a single document can contain across all
+    `nested` types. This limit helps to prevent out of memory errors when a document contains too many nested
+    objects. Default is `10000`.
+// end::nested-objects-limit[]
+
+`index.mapping.field_name_length.limit`::
+    Setting for the maximum length of a field name. This setting isn't really something that addresses
+    mappings explosion but might still be useful if you want to limit the field length.
+    It usually shouldn't be necessary to set this setting. The default is okay
+    unless a user starts to add a huge number of fields with really long names. Default is
+    `Long.MAX_VALUE` (no limit).