[Authz] Operator privileges (#196583)

## Summary

This PR adds support for explicit indication whether endpoint is
restricted to operator only users.

### Context
1. If user has [all operator
privileges](https://github.com/elastic/elasticsearch/blob/main/x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/operator/DefaultOperatorOnlyRegistry.java#L35-#L53)
granted, but is not listed as operator in `operator_users.yml`, ES would
throw an unauthorized error.
2. If user is listed as operator in `operator_users.yml`, but doesn't
have necessary privileges granted, ES would throw an unauthorized error.
3. It’s not possible to determine if a user is operator via any ES API,
i.e. `_has_privileges`.
4. If operator privileges are disabled we skip the the check for it,
that's why we require to explicitly specify additional privileges to
ensure that the route is protected even when operator privileges are
disabled.

### Checklist

- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios

__Relates: https://github.com/elastic/kibana/issues/196271__

### How to test

1. Add your user to the operators list
1bd8144924/packages/kbn-es/src/serverless_resources/operator_users.yml (L4)
or use existing user from the list to log in.
2. Run ES and Kibana serverless
3. Change any endpoint or create a new one with the following security
config
```
      security: {
        authz: {
          requiredPrivileges: [ReservedPrivilegesSet.operator],
        },
      },
```
4. Check with enabled and disabled operator privileges (set
`xpack.security.operator_privileges.enabled`)

## Release Note
Added support for explicit indication whether endpoint is restricted to
operator only users at the route definition level.

---------

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

dev_docs/key_concepts/api_authorization.mdx

@@ -102,6 +102,38 @@ router.get({
 }, handler);
 ```
 
+### Configuring operator and superuser privileges
+We have two special predefined privilege sets that can be used in security configuration:
+1. Operator
+```ts
+router.get({
+  path: '/api/path',
+  security: {
+    authz: {
+      requiredPrivileges: [ReservedPrivilegesSet.operator, '<privilege_2>'],
+    },
+  },
+  ...
+}, handler);
+```
+Operator privileges check is enforced only if operator privileges are enabled in the Elasticsearch configuration.
+For more information on operator privileges, refer to the [Operator privileges documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/operator-privileges.html).
+If operator privileges are disabled, we skip the check for it, so the only privilege checked from the example above is `<privilege_2>`.
+Operator privileges cannot be used as standalone, it is required to explicitly specify additional privileges in the configuration to ensure that the route is protected even when operator privileges are disabled.
+
+2. Superuser
+```ts
+router.get({
+  path: '/api/path',
+  security: {
+    authz: {
+      requiredPrivileges: [ReservedPrivilegesSet.superuser],
+    },
+  },
+  ...
+}, handler);
+```
+
 ### Opting out of authorization for specific routes
 **Before migration:**
 ```ts
@@ -291,7 +323,7 @@ GET /api/oas?pathStartsWith=/your/api/path
 ## Migrating from `access` tags to `security` configuration
 We aim to use the same privileges that are currently defined with tags `access:<privilege_name>`.
 To assist with this migration, we have created eslint rule `no_deprecated_authz_config`, that will automatically convert your `access` tags to the new `security` configuration.
-It scans route definitions and converts `access` tags to the new `requiredPriviliges` configuration.
+It scans route definitions and converts `access` tags to the new `requiredPrivileges` configuration.
 
 Note: The rule is disabled by default to avoid automatic migrations without an oversight. You can perform migrations by running: