Add API key ID to error message for invalid credentials

[ywangd]

When the credentials fails to verify, the error message does not tell which API key fails. This makes it hard for users to fix the issue. This PR adds the API key ID to the error message to help with the situation.

[elasticsearchmachine]

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

[n1v0lg]

LGTM.

I'm wondering if it makes sense to more broadly tweak our generic error message for such cases:

elasticsearch/x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/AuthenticatorChain.java

Lines 299 to 303 in 295c6f0

	final ElasticsearchSecurityException eseWithPreviousCredentials = new ElasticsearchSecurityException(
	"unable to authenticate with provided credentials and anonymous access is not allowed for this request",
	ese.status(),
	ese.getCause()
	);

to include the principal of the most recent authentication token, when available. It's orthogonal, but could potentially cover more useful cases. So something like:

final ElasticsearchSecurityException eseWithPreviousCredentials = new ElasticsearchSecurityException(
    "unable to authenticate with provided credentials with ID [" + getPrincipalOfMostRecentTokenIfAvailable() + "] and anonymous access is not allowed for this request",
    ese.status(),
    ese.getCause()
);

[ywangd]

I'm wondering if it makes sense to more broadly tweak our generic error message for such cases

Probably. But the original intention for authentication chain is that multiple authentication tokens can be extracted by different Authenticators. That's why Authenticator.Context.authenticationTokens is a List<AuthenticationToken>. But we never got the chance to actually implement the rest of it. So right now it has only 0 or 1 AuthenticationToken. If we ever going to have mulitple authenticaiton tokens, it would be a bit cubmersome to squeeze them all into the single error message. So right now the structure is to let each individual additional_unsuccessful_credentials report more details. I think we will always need the credential ID in the additional messages because otherwise it is not clear which credentials failed for a specific additional message. In this case, listing the credentials IDs in the overall message again is sorta redundant.