The get aliases api should not return entries for data streams with no aliases

[martijnvg]

The get alias api should take into account the aliases parameter when
returning aliases that refer to data streams and don't return entries
for data streams that don't have any aliases pointing to it.

Relates to #66163

[elasticmachine]

Pinging @elastic/es-core-features (Team:Core/Features)

[danhermann]

I don't know if this PR is intended to address this, but when testing this API, GET _alias returns data stream aliases but if GET _alias/dataStreamAlias is attempted, a 404 is returned.

[martijnvg]

I don't know if this PR is intended to address this, but when testing this API, GET _alias returns data stream aliases but if GET _alias/dataStreamAlias is attempted, a 404 is returned.

I completely missed that. This is a different bug in RestGetAliasesAction#buildRestResponse(...) method.
In order to fix that, I think this method needs to add the data stream alias names to the returnedAliasNames variable.
Do you want this to be fixed in this PR or another PR?

This PR avoids returning entries for data streams that don't match with the provided alias name.
For example without this change, in a cluster with 2 data streams and an alias with name logs then executing GET /_alias/wrong-name returns:

{
    "error": "alias [wrong_name] missing",
    "status": 404,
    "ilm-history-5": {
        "aliases": {}
    },
    "logs-bar-baz": {
        "aliases": {}
    },
    "logs-foo-bar": {
        "aliases": {}
    }
}

While the following is expected:

{
    "error": "alias [wrong_name] missing",
    "status": 404
}

(at least this matches the behaviour with aliases pointing to indices)

[danhermann]

Do you want this to be fixed in this PR or another PR?

Another PR is fine. I was just testing it in an attempt to understand what this PR did. Thanks for the explanation.