Access denied messages for indices were overly brief and missed two
pieces of useful information:

1. The names of the indices for which access was denied
2. The privileges that could be used to grant that access

This change improves the access denied messages for index based
actions by adding the index and privilege names.
Privilege names are listed in order from least-privilege to
most-privileged so that the first recommended path to resolution is
also the lowest privilege change.

Relates: elastic#42166
Backport of: elastic#60357

In elastic#60357 we improved the error message when access to perform an
action on an index was denied by including the index name and the
privileges that would grant the action.

This commit extends the second part of that change (the list of
privileges that would resolve the problem) to situations when a
cluster action is denied.

This implementation for cluster privileges is slightly more complex
than that of index privileges because cluster privileges can be
dependent on parameters in the request, not just the action name.
For example, "manage_own_api_key" should be suggested as a matching
privilege when a user attempts to create an API key, or delete their
own API key, but should not be suggested when that same user attempts
to delete another user's API key.

Relates: elastic#42166

Access denied messages for indices were overly brief and missed two
pieces of useful information:

1. The names of the indices for which access was denied
2. The privileges that could be used to grant that access

This change improves the access denied messages for index based
actions by adding the index and privilege names.
Privilege names are listed in order from least-privilege to
most-privileged so that the first recommended path to resolution is
also the lowest privilege change.

Backport of: #60357

In #60357 we improved the error message when access to perform an
action on an index was denied by including the index name and the
privileges that would grant the action.

This commit extends the second part of that change (the list of
privileges that would resolve the problem) to situations when a
cluster action is denied.

This implementation for cluster privileges is slightly more complex
than that of index privileges because cluster privileges can be
dependent on parameters in the request, not just the action name.
For example, "manage_own_api_key" should be suggested as a matching
privilege when a user attempts to create an API key, or delete their
own API key, but should not be suggested when that same user attempts
to delete another user's API key.

Relates: #42166

Some actions that start with "indices:" are actually handled by
cluster privileges in ES security (e.g. indices:admin/template/*)
In elastic#60357 and elastic#66900 we added better context information for the
error messages that are generated when an action is denied, but the
generation of that message did not correctly classify actions between
cluster and index level privileges.

This change does 2 things:
1. It fixes the code that determines whether an action is handled by a
   cluster privilege or an index privilege
2. Includes the words "cluster" and "index" in the error message so
   that classification is clear to the reader

The latter change is not directly related to the issue being resolved,
but in the course of fixing the issue it became evident that the
message lacked clarity because it did not tell the reader what type of
privilege would be needed to resolve the access denied issue.

Resolves: elastic#68144

In elastic#60357 we improved the error message when access to perform an
action on an index was denied by including the index name and the
privileges that would grant the action.

This commit extends the second part of that change (the list of
privileges that would resolve the problem) to situations when a
cluster action is denied.

This implementation for cluster privileges is slightly more complex
than that of index privileges because cluster privileges can be
dependent on parameters in the request, not just the action name.
For example, "manage_own_api_key" should be suggested as a matching
privilege when a user attempts to create an API key, or delete their
own API key, but should not be suggested when that same user attempts
to delete another user's API key.

Backport of: elastic#66900

Some actions that start with "indices:" are actually handled by
cluster privileges in ES security (e.g. indices:admin/template/*)
In #60357 and #66900 we added better context information for the
error messages that are generated when an action is denied, but the
generation of that message did not correctly classify actions between
cluster and index level privileges.

This change does 2 things:
1. It fixes the code that determines whether an action is handled by a
   cluster privilege or an index privilege
2. Includes the words "cluster" and "index" in the error message so
   that classification is clear to the reader

The latter change is not directly related to the issue being resolved,
but in the course of fixing the issue it became evident that the
message lacked clarity because it did not tell the reader what type of
privilege would be needed to resolve the access denied issue.

Resolves: #68144

In #60357 we improved the error message when access to perform an
action on an index was denied by including the index name and the
privileges that would grant the action.

This commit extends the second part of that change (the list of
privileges that would resolve the problem) to situations when a
cluster action is denied.

This implementation for cluster privileges is slightly more complex
than that of index privileges because cluster privileges can be
dependent on parameters in the request, not just the action name.
For example, "manage_own_api_key" should be suggested as a matching
privilege when a user attempts to create an API key, or delete their
own API key, but should not be suggested when that same user attempts
to delete another user's API key.

Backport of: #66900

Some actions that start with "indices:" are actually handled by
cluster privileges in ES security (e.g. indices:admin/template/*)
In elastic#60357 and elastic#66900 we added better context information for the
error messages that are generated when an action is denied, but the
generation of that message did not correctly classify actions between
cluster and index level privileges.

This change does 2 things:
1. It fixes the code that determines whether an action is handled by a
   cluster privilege or an index privilege
2. Includes the words "cluster" and "index" in the error message so
   that classification is clear to the reader

The latter change is not directly related to the issue being resolved,
but in the course of fixing the issue it became evident that the
message lacked clarity because it did not tell the reader what type of
privilege would be needed to resolve the access denied issue.

Backport of: elastic#68260

Some actions that start with "indices:" are actually handled by
cluster privileges in ES security (e.g. indices:admin/template/*)
In #60357 and #66900 we added better context information for the
error messages that are generated when an action is denied, but the
generation of that message did not correctly classify actions between
cluster and index level privileges.

This change does 2 things:
1. It fixes the code that determines whether an action is handled by a
   cluster privilege or an index privilege
2. Includes the words "cluster" and "index" in the error message so
   that classification is clear to the reader

The latter change is not directly related to the issue being resolved,
but in the course of fixing the issue it became evident that the
message lacked clarity because it did not tell the reader what type of
privilege would be needed to resolve the access denied issue.

Backport of: #68260

Our authorization engine has a short-circuit check for the intended
action the takes place before resolving index names (wildcards).

That is, a requests like

    GET /_search
    GET /logs-*/_search
    GET /logs-20210414/_search

will fail fast if the user does not have read permission on any
indices, and we will never resolve the list of indices that the
request targets.

Consequently, it is impossible to provide the list of denied indices
in the error message because that list does exist (and, in the case of
wildards would be empty even if we did resolve it).

This change updates the access denied message so that it does not
attempt to include the list of indices if the IndiceAccessControl
object has an empty list of denied indices.

Prior to this, we would generate messages such as

    action [indices:data/read/search] is unauthorized for user [test]
    with roles [test] on indices [],

That "indices []" section is never useful since it does not name any
indices, so it has now been dropped from the message if it is empty.

Relates: elastic#42166, elastic#60357

Our authorization engine has a short-circuit check for the intended
action the takes place before resolving index names (wildcards).

That is, a requests like

    GET /_search
    GET /logs-*/_search
    GET /logs-20210414/_search

will fail fast if the user does not have read permission on any
indices, and we will never resolve the list of indices that the
request targets.

Consequently, it is impossible to provide the list of denied indices
in the error message because that list does exist (and, in the case of
wildards would be empty even if we did resolve it).

This change updates the access denied message so that it does not
attempt to include the list of indices if the IndicesAccessControl
object has an empty list of denied indices.

Prior to this, we would generate messages such as

    action [indices:data/read/search] is unauthorized for user [test]
    with roles [test] on indices [],

That "indices []" section is never useful since it does not name any
indices, so it has now been dropped from the message if it is empty.

Relates: #42166, #60357

Our authorization engine has a short-circuit check for the intended
action the takes place before resolving index names (wildcards).

That is, a requests like

    GET /_search
    GET /logs-*/_search
    GET /logs-20210414/_search

will fail fast if the user does not have read permission on any
indices, and we will never resolve the list of indices that the
request targets.

Consequently, it is impossible to provide the list of denied indices
in the error message because that list does not exist (and, in the
case of wildards would be empty even if we did resolve it).

This change updates the access denied message so that it does not
attempt to include the list of indices if the IndicesAccessControl
object has an empty list of denied indices.

Prior to this, we would generate messages such as

    action [indices:data/read/search] is unauthorized for user [test]
    with roles [test] on indices [],

That "indices []" section is never useful since it does not name any
indices, so it has now been dropped from the message if it is empty.

Relates: elastic#42166, elastic#60357
Backport of: elastic#71715