Add project_routing query param to _search and _async_search

[quux00]

Adds the project_routing query param to the _search and _async_search endpoints
but only in serverless behind the feature flag "serverless.cross_project.enabled".
This param is not available in stateful ("stack").

[github-actions]

Following you can find the validation changes against the target branch for the APIs.

No changes detected.

You can validate these APIs yourself by using the make validate target.

[l-trotta]

@quux00 thanks! waiting for the server side PR to be merged. just to be sure, is the only value allowed _alias:something? would it make sense to have the user only input the customizable part of the string?

[quux00]

I see these on another PR:

@availability serverless stability=stable visibility=public

Do I need to add those? What are the other possible values?

[l-trotta]

they are optional, but nice to have. possible values:

• stability: stable, experimental, unknown
• visibility: public, private, feature_flag

in case of visibility=feature_flag you can also add an optional feature_flag={name of the feature flag}.
lastly there's since, which indicates (for stack) the version where the endpoint/field was introduced.
complete example:

elasticsearch-specification/specification/_global/search/SearchRequest.ts

Line 389 in 3a98596

* @availability stack since=8.4.0 visibility=feature_flag feature_flag=es.index_mode_feature_flag_registered

[quux00]

Got it thanks. I'll add that in the next push.

[quux00]

@l-trotta

is the only value allowed _alias:something? would it make sense to have the user only input the customizable part of the string?

For now that is the only allowed entry, but in the future we will allow arbitrary key/value pairs with AND/OR/NOT booleans and boolean groupings, using Lucene query syntax, so I don't think we want additional constraints in the spec.

[JoshMock]

@quux00 is this all the APIs we know of for now that will support CPS project routing rules? If not, the sooner we get those into the spec the better, as they'll be necessary to support the middleware Kibana needs.

Otherwise, LGTM.

[pquentin]

@JoshMock There's #5277 too!

[quux00]

s this all the APIs we know of for now that will support CPS project routing rules? If not, the sooner we get those into the spec the better, as they'll be necessary to support the middleware Kibana needs.

No, there are several more. Those PR(s) will be out later this week.