This commit introduces minimal service settings in the model registry, accessible without querying the inference index.
These settings are now available for the default models exposed by the inference service.

The ability to access settings without an inference index query is needed for the semantic text field, as it would benefit from eager validation of configuration during field creation.
This is not feasible currently because retrieving service settings relies on an asynchronous call to the inference index.

### Follow-Up Plans:
1. Extend this capability to include minimal service settings for all newly added models, making them accessible via the cluster state.
2. Update the semantic text field to eagerly retrieve service settings directly from the model registry.

…csearch.xpack.esql.qa.multi_node.RestEsqlIT elastic#120948

…ic#120934)

This reverts commit 43e3e24.

…st {p0=nodes.stats/11_indices_metrics/indices mappings exact count test for indices level} elastic#120950

This implements an interface that export the names of the plan nodes and
functions that need to be counted in the metrics.

Also, the metrics are now counted from within the parser. This should
allow correct accounting for the cases where some nodes can appear both
standalone or part other nodes' children (like Aggregate being a child
of INLINESTATS, so no STATS counting should occur).

The functions counting now also validates that behind a name there is
actually a function registered.

Closes elastic#115992.

…trips is true (elastic#117504)

* Fix NPE caused by race condition in async search when minimise round trips is true

Previously, the `notifyListShards()` initialised and updated the
required pre-requisites (`searchResponse` being amongst them) when a
search op began. This function takes in arguments that contain
shard-specific details amongst others. Because this information is not
immediately available when the search begins, it is not immediately
called. In some specific cases, there can be a race condition that can
cause the pre-requisities (such as `searchResponse`) to be accessed
before they're initialised, causing an NPE.

This fix addresses the race condition by splitting the initialisation
and subsequent updation amongst 2 different methods. This way, the
pre-requisities are always initialised and do not lead to an NPE.

* Try: call `notifyListShards()` after `notifySearchStart()` when minimize round trips is true

* Add removed code comment

* Pass `Clusters` to `SearchTask` rather than using progress listener to
signify search start.

To prevent polluting the progress listener with unnecessary search
specific details, we now pass the `Clusters` object to `SearchTask` when
a search op begins. This lets `AsyncSearchTask` access it and use it to
initialise `MutableSearchResponse` appropriately.

* Use appropriate `clusters` object rather than re-building it

* Do not double set `mutableSearchResponse`

* Move mutable entities such as shard counts out of `MutableSearchResponse`

* Address PR review: revert moving out mutable entities from
`MutableSearchResponse`

* Update docs/changelog/117504.yaml

* Get rid of `SetOnce` for `searchResponse`

* Drop redundant check around shards count

* Add a test that calls `onListShards()` at last and clarify `updateShardsAndClusters()`'s comment

* Fix test: ref count

* Address review comment: rewrite comment and test

…stic#119003)