Forward port release notes for v8.15.2

docs/reference/release-notes/8.15.2.asciidoc

@@ -0,0 +1,42 @@
+[[release-notes-8.15.2]]
+== {es} version 8.15.2
+
+Also see <<breaking-changes-8.15,Breaking changes in 8.15>>.
+
+[[bug-8.15.2]]
+[float]
+=== Bug fixes
+
+Authorization::
+* Fix remote cluster credential secure settings reload {es-pull}111535[#111535]
+
+ES|QL::
+* ESQL: Don't mutate the `BoolQueryBuilder` in plan {es-pull}111519[#111519]
+* ES|QL: Fix `ResolvedEnrichPolicy` serialization (bwc) in v 8.15 {es-pull}112985[#112985] (issue: {es-issue}112968[#112968])
+* Fix union-types where one index is missing the field {es-pull}111932[#111932] (issue: {es-issue}111912[#111912])
+* Support widening of numeric types in union-types {es-pull}112610[#112610] (issue: {es-issue}111277[#111277])
+
+Infra/Core::
+* JSON parse failures should be 4xx codes {es-pull}112703[#112703]
+* Json parsing exceptions should not cause 500 errors {es-pull}111548[#111548] (issue: {es-issue}111542[#111542])
+* Make sure file accesses in `DnRoleMapper` are done in stack frames with permissions {es-pull}112400[#112400]
+
+Ingest Node::
+* Fix missing header in `put_geoip_database` JSON spec {es-pull}112581[#112581]
+
+Logs::
+* Fix encoding of dynamic arrays in ignored source {es-pull}112713[#112713]
+
+Mapping::
+* Full coverage of ECS by ecs@mappings when `date_detection` is disabled {es-pull}112444[#112444] (issue: {es-issue}112398[#112398])
+
+Search::
+* Fix parsing error in `_terms_enum` API {es-pull}112872[#112872] (issue: {es-issue}94378[#94378])
+
+Security::
+* Allowlist `tracestate` header on remote server port {es-pull}112649[#112649]
+
+Vector Search::
+* Fix NPE in `dense_vector` stats {es-pull}112720[#112720]
+
+

docs/reference/release-notes/highlights.asciidoc

@@ -72,16 +72,54 @@ version 8.16 `allow_rebalance` setting defaults to `always` unless the legacy al
 [discrete]
 [[add_global_retention_in_data_stream_lifecycle]]
 === Add global retention in data stream lifecycle
-Data stream lifecycle now supports configuring retention on a cluster level, namely global retention. Global retention 
-allows us to configure two different retentions:
+Data stream lifecycle now supports configuring retention on a cluster level,
+namely global retention. Global retention \nallows us to configure two different
+retentions:
 
-- `data_streams.lifecycle.retention.default` is applied to all data streams managed by the data stream lifecycle that do not have retention
-defined on the data stream level.
-- `data_streams.lifecycle.retention.max` is applied to all data streams managed by the data stream lifecycle and it allows any data stream 
-data to be deleted after the `max_retention` has passed.
+- `data_streams.lifecycle.retention.default` is applied to all data streams managed
+by the data stream lifecycle that do not have retention defined on the data stream level.
+- `data_streams.lifecycle.retention.max` is applied to all data streams managed by the
+data stream lifecycle and it allows any data stream \ndata to be deleted after the `max_retention` has passed.
 
 {es-pull}111972[#111972]
 
+[discrete]
+[[enable_zstandard_compression_for_indices_with_index_codec_set_to_best_compression]]
+=== Enable ZStandard compression for indices with index.codec set to best_compression
+Before DEFLATE compression was used to compress stored fields in indices with index.codec index setting set to
+best_compression, with this change ZStandard is used as compression algorithm to stored fields for indices with
+index.codec index setting set to best_compression. The usage ZStandard results in less storage usage with a
+similar indexing throughput depending on what options are used. Experiments with indexing logs have shown that
+ZStandard offers ~12% lower storage usage and a ~14% higher indexing throughput compared to DEFLATE.
+
+{es-pull}112665[#112665]
+
 // end::notable-highlights[]
 
 
+[discrete]
+[[esql_multi_value_fields_supported_in_geospatial_predicates]]
+=== ESQL: Multi-value fields supported in Geospatial predicates
+Supporting multi-value fields in `WHERE` predicates is a challenge due to not knowing whether `ALL` or `ANY`
+of the values in the field should pass the predicate.
+For example, should the field `age:[10,30]` pass the predicate `WHERE age>20` or not?
+This ambiguity does not exist with the spatial predicates
+`ST_INTERSECTS` and `ST_DISJOINT`, because the choice between `ANY` or `ALL`
+is implied by the predicate itself.
+Consider a predicate checking a field named `location` against a test geometry named `shape`:
+
+* `ST_INTERSECTS(field, shape)` - true if `ANY` value can intersect the shape
+* `ST_DISJOINT(field, shape)` - true only if `ALL` values are disjoint from the shape
+
+This works even if the shape argument is itself a complex or compound geometry.
+
+Similar logic exists for `ST_CONTAINS` and `ST_WITHIN` predicates, but these are not as easily solved
+with `ANY` or `ALL`, because a collection of geometries contains another collection if each of the contained
+geometries is within at least one of the containing geometries. Evaluating this requires that the multi-value
+field is first combined into a single geometry before performing the predicate check.
+
+* `ST_CONTAINS(field, shape)` - true if the combined geometry contains the shape
+* `ST_WITHIN(field, shape)` - true if the combined geometry is within the shape
+
+{es-pull}112063[#112063]
+