Remove support for fielddata loading on _id.

[jtibshirani]

In 7.6 we introduced a cluster setting to prevent fielddata loading on _id (#49166). In a future version, we'd like to go further and remove support for loading fielddata on _id entirely.

The reasoning: _id fielddata can use substantial heap memory, making it more complex to manage Elasticsearch. At the same time, it's uncommon to require fielddata on _id:

• The main use case for sorting on _id is to achieve a consistent order in search_after requests. We plan to introduce a dedicated way to tiebreak in point-in-time searches that does not require _id (Virtual Sort field for automatic tie-breaking #56828).
• It's hard to think of a strong use case for aggregating on _id.

[elasticmachine]

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

[elasticmachine]

Pinging @elastic/es-analytics-geo (:Analytics/Aggregations)

[ppf2]

Before we remove support for this from Elasticsearch, let's also make sure that we address the outstanding Kibana issue (elastic/kibana#57181) where it is using aggregations against the _id field for autocomplete features (and anywhere in Kibana we may be using _id for sorting/aggregations/scripting). @alexfrancoeur @AlonaNadler

[mitar]

The use case I have for fielddata on _id (but it could also be just doc values on _id, see #60778) is that I want to predictably but randomly sort results which have the same score. So I am using random_score scoring function on _id field with random seed tied to the user (so that user has same ordering even if they redo the query). By removing fielddata such random tiebreaking would not be possible.

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)

[elasticsearchmachine]

Pinging @elastic/es-search-foundations (Team:Search Foundations)