@elasticmachine run elasticsearch-ci/rest-compatibility (unrelated failure, as usual these days)

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

Thanks @romseygeek!

@ywelsch could you give the background on why we're restoring support for searching and returning _type?

Sure, it's for accessing archival data (#81210) where users will have the ability to access their older raw data. Here, _type is part of the "original data" that the user provided to the system (but isn't stored in _source, similar to _id), so this PR adds support for them to be able to retrieve this data and to run basic queries on it.

Got it, so we're adding some minimal handling for _type as this could store valuable data for 5.x indices. One other question -- I assume this re-adds a top-level _type key to the search response. Does this interact okay with 7.x compatibility, which also adds this (https://github.com/elastic/elasticsearch/blob/master/server/src/main/java/org/elasticsearch/search/SearchHit.java#L627-L629)?

Got it, so we're adding some minimal handling for _type as this could store valuable data for 5.x indices. One other question -- I assume this re-adds a top-level _type key to the search response.

Correct. This is handled quite nicely in newer ES versions, which do that (top-level key) automatically for any metadata mapper.

Does this interact okay with 7.x compatibility, which also adds this (https://github.com/elastic/elasticsearch/blob/master/server/src/main/java/org/elasticsearch/search/SearchHit.java#L627-L629)?

Interesting. This interacts badly, as the _type key would be added twice now (the existing RestApiVersion check should have accounted for that possibility). I can follow-up with a small fix here (low priority).