Example backend of Security for Extensions for Integration Testing

[cwperks]

This PR contains an example of Service Account Token and On-Behalf-Of Token implementations that can be used for integrating and testing with extensions. This PR defines a few security settings for extensions in the OpenSearchSecurityPlugin.getExtensionSettings() that can be used on an extension initialization request. An example initialization request looks like:

curl -XPOST https://admin:admin@localhost:9200/_extensions/initialize --insecure -H "Content-Type:application/json" --data '{
    "name":"hello-world",
    "uniqueId":"hw",
    "hostAddress":"127.0.0.1",
    "port":"4532",
    "version":"1.0",
    "opensearchVersion":"3.0.0",
    "minimumCompatibleVersion":"3.0.0",
    "reserved_indices": [".hello-world-jobs"],
    "permissions.cluster_permissions": ["cluster_composite_ops_ro"],
    "permissions.index_permissions.0.index_patterns": ["*"],
    "permissions.index_permissions.0.allowed_actions": ["read"],
    "send_backend_roles": true
}'

Where reserved_indices, permissions.* and send_backend_roles are security settings for the extension.

1. reserved_indices - This settings let's an extension reserve indices that would grant them system index protection from the security plugin. The service account token generated on this PR is an ID Token and does not contain any authz information in the token, unlike on-behalf-of tokens.

This token is narrowly scoped to only permit an extension to meddle with the indices that its reserved and nothing else. This token has a narrow scope to allow for system index use-cases that plugins rely on today and limit the blast radius in the event one is compromised.

2. permissions.* - These can be ignored, but they are a proof of concept to show what it could look like to grant more permissions to a service account token then the narrow use-case of only requests on a reserved (system) index. Theoretically, this would allow for "daemon" extensions that operate in the background with a known set of permissions. This would provide an alternative to setting up a microservice utilizing an opensearch client with a username + password combo.

3. send_backend_roles - This flag indicates that an on-behalf-of token should include the user's backend roles as a claim in the payload of the token. This is necessary for extension's, like anomaly-detection, that provide additional attribute-based security of detector's based on user's backend roles. By default, backend roles would not be included as a claim in the payload of the on-behalf-of JWT that is ferried to an extension.