Add exception metadata for disabled features

[tvernum]

This change adds a new exception with consistent metadata for when
security features are not enabled. This allows clients to be able to
tell that an API failed due to a configuration option, and respond
accordingly.

Relates: elastic/kibana#55255
Resolves: #52311, #47759

---

Sample REST output

{
  "error" : {
    "root_cause" : [
      {
        "type" : "feature_not_enabled_exception",
        "reason" : "security tokens are not enabled",
        "disabled.feature" : "security_tokens"
      }
    ],
    "type" : "feature_not_enabled_exception",
    "reason" : "security tokens are not enabled",
    "disabled.feature" : "security_tokens"
  },
  "status" : 400
}

For now, possible feature names are security_tokens and api_keys

[elasticmachine]

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

[tvernum]

Ping @kobelb

[tvernum]

Ping @cjcenizal

[ywangd]

I have some questions around the Feature concept. Please see above (below actually). Thanks.

[ywangd]

I wonder whether we should give Feature more attention to make it more formalized, because it seems to be an useful concept for other places as well. By formalization, I mean something like, have it in a separate class, place it in a shared package which is more accessible, name each feature more consistently (more on this below).

Including Feature, we now have three different but related concepts: Feature, Setting, Plugin. Plugin seems to be the highest level, in that it provides one or multiple Features and Settings. I am not sure whether Feature has an 1-to-1 relationship with a Setting. If so, I feel the associated Setting should be reflected in this class and this could be useful for users to act accordingly.

If the relationship between Feature and Setting is more complex, e.g. a feature corresponds to multiple Settings working together, it may need to be more carefully defined and promoted to be a first level concept. I am a bit surprised that Feature is not already an existing concept since both Setting and Plugin sound too technical when talking to users, while Feature seem to be a more accessible term.

I am aware that it is not something inherent to this PR so we don't need to solve it all with this PR. One possible actionable item is to move this class to a more common package for reuse by places other than security.

[tvernum]

Yes, no, maybe...

We do have "feature" concepts throughout the codebase. The obvious example being isXyzzyAllowed() on XPackLicenseState. Those are, roughly speaking, features.

I can imagine a world when we had strong model of "Feature" and the license checks where all isFeatureAllowed(Feature feature), and elsewhere isFeatureEnabled(Feature), but we don't and I don't think anyone wants to.

The reason I added an enum here is

1. So that the feature names were static & defined in a single place, so that clients could rely on the names being a well defined set (at least, per version).
2. I could have solved that with constant Strings, but then the exception constructor would have been (String, String, Object ...) and there would be ambiguity about which String was the feature name and which was the message.

I think there's something to your suggestion, but progress over perfection - to me, this is a straight forward solution to the problem at hand, and we can evolve it into something else in the future if we need.

[ywangd]

Enum is good (at least for now). I agree that we don't wanna stall on something that is not in scope of the problem at hand. My actual question is whether we should move this file to a more common module, e.g. the xpack core module for dependency sake, since I can see it being useful for other xpack modules besides security (similar to how license related files are in core).

[tvernum]

My personal view, is that it's a false sense of "reuse".
As it stands:

1. we don't know if this would be useful elsewhere. We can imagine places, but we have no plans to change them
2. because of (1), we also don't know which enum values would make sense in the future
3. we do know that future uses of it would be constrained by not being able to change it significantly because they'd risk breaking clients.

Based on the above, I understand the temptation to put it in core, but there's no clear value, and 1 definite limitation, so it seems like something that feels good for reuse purposes, but actually isn't.

[ywangd]

I was thinking about using it in the "role template validation" if we chose to issue warning instead of error out. Since we have decided it's ok to error out, I currently have no other idea where it could be re-used. So the current form is ok with me.

[albertzaharovits]

LGTM, sorry for the delay, I missed the notification.

Maybe update the PR description with a sample listing of the exception, it might save clients folks some time:

{
  "error" : {
    "root_cause" : [
      {
        "type" : "feature_not_enabled_exception",
        "reason" : "security tokens are not enabled",
        "disabled.feature" : "security_tokens"
      }
    ],
    "type" : "feature_not_enabled_exception",
    "reason" : "security tokens are not enabled",
    "disabled.feature" : "security_tokens"
  },
  "status" : 400
}

[ywangd]

LGTM