Improve Licensing plugin API

[pgayvallet]

Initial discussion started here: #63549 (comment)

In #60984 we introduced a new featureUsage API to the licensing plugin to allow plugins to notify of their licensed feature usages.

However this initial implementation has a major flaw in the fact that it's totally decorrelated from the license checking API, meaning that a developer has to perform distinct calls to check for a license permission and then to notify that the feature was used. In addition to being poor developer experience, there is also a risk that the developer forget to use the notify API when needed.

The initial discussion also revealed that the licensing API could probably use some sugar for the most common use cases regarding license checking

We should have a common API for license checking that should allow to check for a feature and notify usage at the same time, or at least allow to perform both operations from a single accessor / service

The implementation should still allow to use the current raw $license access for more complex usages.

Suggested solution from original discussion is to introduce a feature object/API to create, check and notify usage of a given feature.

Some possible base implementations:

• with a createFeature(s) API

// exists **only** within a plugin scope
const pluginFeatues = licensing.createPluginFeatures({
  sub-feature: (license: ILicense) => ....,
});

// in an endpoint
if(
  context.plugin.license.isAvailable &&
  // automatically reports sub-feature usage if returns true
  pluginFeatues.check('sub-feature')
){
  return res.ok(...)
}
return res.forbidden(...)

• with an abstract base class

abstract class KibanaFeature implements LicensedFeature {
  constructor(license$: Observable<ILicense>){
    license$.subscribe(license => {
       this.valid = license.isAvailable && license.hasAtLeast('gold');
    })
  }
  eligibleForUsage(){
     return this.valid
  }
  notifyUsage() {}
}
class RbacFeature extends KibanaFeature {
  doSomething(){
    this.notifyUsage()
    return ...
  }
}

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[blfrantz]

@kobelb FYI, per our recent discussion on this topic, I've added our preferred API response to the bottom of the description of https://github.com/elastic/cloud/issues/51132.

[blfrantz]

@kobelb Following up on our discussion from back in July about adding a "description" to the featureUsage API. I wanted to make sure this request was still on your radar and tracked somewhere. Would that be this ticket or do we need to create another one? For reference, ES is tracking theirs here. Thanks!

[kobelb]

Hey @blfrantz, apologies for dropping the ball on this request. We definitely can make it part of the new API, and honestly that'd be easiest. However, if you need it sooner rather than later, we can make it part of the legacy API as well. Prior to us having the description available provided by the Kibana API, do we have a reasonable workaround? Or should we prioritize the description being added to the legacy API?

[blfrantz]

We do have a workaround (defining these descriptions in Cloud) and honestly need it anyway for older stack versions, so this is mainly to ensure that as features are added over the long-term, Cloud doesn't have to keep adding them to our mapping. Do you have a rough time estimate for the "new API?" If it's not too far off, I think it's fine to just focus on adding this there.

[kobelb]

I believe this is currently targeting 7.12. @joshdover, can you confirm?

[joshdover]

Yes, 7.12 is the current plan.

[pgayvallet]

We never really got any momentum on that issue, so I'll assume we don't really need it and close it.