Deprecate types in count and msearch.

[jtibshirani]

This PR deprecates types in the count and multi-search APIs, and adds tests for types deprecation in the search API.

For each API, the following updates were made:

• Add deprecation warnings to Rest*Action, plus tests in Rest*ActionTests.
• For each REST yml test, create one version without types, and another legacy version that retains types (called *_with_types.yml).
• Deprecate relevant methods on the Java HLRC requests/ responses.
• Update documentation (for both the REST API and Java HLRC).

For the Java HLRC, I decided not to duplicate each request/ response class as we had discussed in #34041. Instead, this PR continues to use the transport classes, and follows the traditional path of deprecating methods. My reasoning for this choice:

• Although the Java HLRC is in 'beta', switching to new request/ response classes would be breaking for many early users of the client. I think it would be great to avoid additional breaks if possible, as users already have a lot to think about in 7.0 with types removal, the transport client migration, hit count tracking, etc.
• Duplicating each of the requests/ responses would add a substantial amount of work to the types deprecation effort, which is already quite an extensive project.

[elasticmachine]

Pinging @elastic/es-search-aggs

[jtibshirani]

@javanna @hub-cap would you be able to take a look at this from the perspective of the Java HLRC? I know we discussed creating a new set of classes for each request/ response in #34041, but it looks like we can keep most of the APIs as they are and follow the traditional path of deprecating methods. I think it would be great to avoid additional breaks if possible, as users already have a lot to think about in 7.0 with the types removal, the Java HLRC migration, hit count tracking, etc.

[markharwood]

Does this need keeping? It warns when invoking URLs of this form:

 GET my_index/_search?type=my_type

[markharwood]

Maybe not for this PR but while we're itemising the ways clients can filter by type this currently also raises no warnings:

GET my_index/_search?q=_type:my_type

or other forms of query:

GET my_index/_search
{
  "query":{
	"match":{
	  "_type":"my_type"
	}
  }
}

[jtibshirani]

Thanks @markharwood! I hadn't considered query parameters at all in this PR, will fix that. I added a note about queries that use _type as a field name to #35190.

[jtibshirani]

@markharwood I think this is ready for another look. Also tagging @jpountz in case he would like to review.

[markharwood]

Is the plan to add _msearch/template checking into this PR too?

[jtibshirani]

No, I was planning to address the search template endpoints separately.

[hub-cap]

I think its perfectly reasonable to do what you did here. I totally agree with your reasoning. !!! (well, ship the HLRC piece, ill let someone else review the server side ;) )

[markharwood]

LGTM