Updatable API keys - REST API spec and tests

[n1v0lg]

This PR adds REST API spec and YAML test files for the UpdateApiKey
operation.

[elasticmachine]

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

[elasticsearchmachine]

Hi @n1v0lg, I've created a changelog YAML for you.

[elasticmachine]

Pinging @elastic/clients-team (Team:Clients)

[n1v0lg]

@elasticmachine run elasticsearch-ci/part-2 plz. Unrelated failure.

[sethmlarson]

@n1v0lg Looks pretty good so far! Thanks for adding so many YAML tests for this API.

[ywangd]

LGTM pending stub doc page as suggested below.

[ywangd]

I am curious why you picked Authentication. I'd go with the generic Security. It's not great either. I don't have a strong opinion, but would like to know your thoughts.

[n1v0lg]

I really wasn't sure here. I went with authentication because API keys generally are related to authentication but it's a bit of a stretch for this PR. I think Security might make more sense.

[ywangd]

I don't think we should clear API key cache after each test since this does not match the real usage pattern, i.e. it is unlikely that users would clear cache every often. I understand this is copied from 10_basic.yml. But those calls were added when API key cache clearing API was initially introduced. So they intentionally excercise the API. But outside that, there is no need (and actually better not to) call this API.

[ywangd]

The YAML tests look fine to me. That said, I just noticed two things in Java tests:

1. There is a bug in ApiKeyIntegTests.testUpdateApiKeyAutoUpdatesUserRoles in that the role definition most often do not change because the putRoleWithClusterPrivileges method only honors the last cluster privilege.
2. We don't seem to have tests for auto-update user information other than role definition changes, e.g. full_name or email changes. Role name change (as opposed to role definition changes) is not covered either.