Handle API key type in Get/Query API key responses

[ywangd]

This PR makes the Get/Query API key APIs to return the new API key type information in their responses. For cross-cluster type API keys, the limited-by field is not shown because they do not use the limited-by model as existing API keys.

Relates: #95714

[ywangd]

This PR has some unfortunate complexity in tests due to this conditional serialization logic with featureFlag checking. A simple solution could be adding assumeTrue(featureFlag) for all those tests. But it felt disabling a bit too much. So I took a more finer controlled approach.

Luckily Doc tests do not actually assert Get/Query responses and Yaml tests only assert selective fields. So they need no change in this PR.

[ywangd]

We may need a new TransportVersion for this given the recent changes to versioning. I am reaching out to the experts for confirmation.

[ywangd]

A new TransportVersion is added f3c58f7

[elasticsearchmachine]

Pinging @elastic/es-security (Team:Security)

[ywangd]

@elasticmachine run elasticsearch-ci/part-1-fips

[n1v0lg]

LGTM!

As a side note, if we ever consider filtering by type, we may be able to add validation that with_limited_by is not used with type=CROSS_CLUSTER since that's arguably an invalid request. It's not really possible to do this for general Get and Query requests though since those can apply to a mix or REST and CROSS_CLUSTER API keys.

[ywangd]

As a side note, if we ever consider filtering by type, we may be able to add validation that with_limited_by is not used with type=CROSS_CLUSTER since that's arguably an invalid request.

Thanks for this idea but I prefer we don't do it. In my opinion, not showing limited_by in the response (effectively null) is a reasonable behaviour for cross_cluster API keys. It means these API keys do not have limited_by roles. As an analogy, we don't error for REST API keys that have no assigned roles. For historical reasons, we show them as empty. But it is not more correct than not showing them at all. It also feels user unfriendly to throw error when the query filters on particular field (type), value (cross_cluster) and requests another particular field (limited_by). It feels better that query parameters are simply additive and not blocking each other. The fields in a search request seems to be a parallel here: we don't error on unknown fields, they are just ignored in response. Technically it is also challenging to implement because there are many ways the type field can be queried and the query field can appear in arbitrary nested boolean clauses.

[ywangd]

@elasticmachine update branch

[ywangd]

@elasticmachine run elasticsearch-ci/part-1

[ywangd]

Failure is not related. I raised #96084

[ywangd]

@elasticmachine run elasticsearch-ci/part-1