Support feature flags to propagate feature support from API backend to consumers

[simonswine]

Is your feature request related to a problem? Please describe.

Currently it is hard for consumers of the Pyroscope APIs to figure out when a new feature has become available.

For example let's say we have a new feature, that adds utf8 support for label names.

Now in order for Drilldown Profiles and/or Alloy to know, that it can use utf-8 labels, it either needs to probe for the support or just trust that the other side has been updated in the same go.

Describe the solution you'd like

I would like Pyroscope to support feature flags, which are accessible for any authenticated Pyroscope API read/write client.

Right now I would like them to be fairly simple and straightforward and only depend on the Pyroscope backend version and it's configuration not necessarily be a thing that is dyanmic per tenant.

As it should be accessible with the same api context, I propose to introduce two calls to querier.v1 and push.v1

rpc GetFeatureFlags({}) returns (types.v1.GetFeatureFlagsResponse) {}

with

message GetFeatureFlagsRespons {
  repeated string support_features = 1;
}

Features should be just strings like:

metricsFromProfiles
metricsFromProfilesFunctions
labelNamesUTF9

The Profiles Drilldown app should ideally only request the backendFeatureFlags once per datasource and then it knows how to treat the backend in the right way.

Describe alternatives you've considered

• We could continue to create a new API call, when something within fields change and probe for it
• For Drilldown we could configure the expected features in the plugin settings and/or data source config. E.g. Prometheus data source is doing that:

Additional context

Talked about this with @ifrost in general and @alsoba13 and @bryanhuhta with enhancing metricsFromProfiles specifically

[aleks-p]

I agree with the general idea!

Perhaps we want to make it slightly more extensible with something like this:

message GetFeatureFlagsRespons {
  repeated Feature features = 1;
}

message Feature {
  string name = 1;
  bool enabled = 2;
}

This could be helpful if a feature has some configuration attached to it.