Support retrieval of all API keys

[cjcenizal]

Currently, GET _security/api_key requires you to provide some identifying information with which to find and retrieve keys. Can we support the retrieval of all API keys by default, in the absence of id, name, realm_name, and username?

CC @bizybot @tvernum @bytebilly @bmcconaghy

[elasticmachine]

Pinging @elastic/es-security

[bytebilly]

@cjcenizal yes this makes sense to me.
Currently, a possible workaround to retrieve the entire list is to call the existing API with all the realms that are configured in the system. I'm not sure if there is a way to obtain the list of realms, but this would not require any backend change in the API code.

A couple of thoughts we could consider as part of this discussion:

1. add the "owner" of the key (principal+realm?) to the response for each entry
2. make it work with the manage_own_api_key, transparently filtering results based on permissions
3. paginate results, if we feel this list could be too long for a single response

[tvernum]

@bizybot will sort this out. It was an oversight due to making the GET and DELETE APIs support the same set of parameters, and intentionally not wanting an DELETE-everything API.

1. add the "owner" of the key (principal+realm?) to the response for each entry

We do that already. If you look at the GET response in the example section of the docs, it has username and realm.

2. make it work with the manage_own_api_key, transparently filtering results based on permissions

It is intentional that we don't so this. We essentially have 2 APIs (though for reasons of history, it's 1 API with an optional parameter).
If you specify owner=true it automatically filters to only show your API keys (if you have access to API keys)
if you specify owner=false (or don't specify it at all, because false is the default), it attempts to show API keys for all owners (if you have access to do so).

We try very hard to have APIs that do what they say, and give you errors if you are not permitted to do so, rather than having APIs that significantly change behaviour depending on your access level.
for the GET API that's not so bad, but for the DELETE API, having it delete your keys if you had manage_own_api_key but delete everyone's keys if you have manage_api_key is the sort of unexpected behaviour we don't want.

3. paginate results, if we feel this list could be too long for a single response

This is a problem today (and not just for API keys, it's also true for listing users).
Interally we do a scroll and collect all the results within the GET API. At some point that will exceed a reasonable usage of memory, and we ought not to do that, but exposing scroll-ids over the security index is a problem (technically we have protections there, but I have a strong preference not to rely on them as our only line of defense).
When we introduce "system indices" and switch the security index across it might be safe enough to hand out an opaque scroll id over than index that isn't accessible via the search APIs.