ConfigCat: forward property for PAID tier (Chargebee or Stripe)

[geropl]

@kylos101 Made a case that it would be nice to filter on paid/free tier in some cases (internal Slack).

We should look into if and how we can implement this with little effort. E.g. maybe by using EntitlementService.hasPaidSubscription or so, and offer that to Team Workspace.

[kylos101]

@geropl it looks like this is part of week 37! 🥳 Is that official? I ask because the issue has no status (is not Scheduled). 🙏

[geropl]

@kylos101 We're experimenting with a new process. Let's see how it works out. Currently, "no status" = no guarantee 😉

[easyCZ]

A couple of notes for this issue:

• Because ConfigCat is declarative, the best we can do is have a property in ConfigCat which is tier and we can match on some enum values (or bool).
• The enum value for a given user can only be determined at runtime and during evaluation of the feature flag - in other words the client that performs the evaluation has to know the value of tier for the given user/workspace etc.
• When using the tier in conjunction with TeamID or other Identifiers, use the confidential text comparators to mask the actual values.

[easyCZ]

Just exploring this issue further to make it implementable.

I'm assuming the goal here is to add a new property to the attributes we can specify in the JS/TS wrapper for ConfigCat.

I'm also assuming we want the property to be something like:
tier = stripe | chargebee or not set when the user is not on a paid subscription.

In ConfigCat, it's not possible to match against multiple properties simultaneously, that is we cannot do teamID = 123 AND tier = stripe. Hence, I'm assuming that the targeting model in ConfigCat will look like the following:

IF teamID = 123 then TRUE
IF tier = stripe then TRUE
IF teamID = 999 then FALSE.

[easyCZ]

Similarly, you cannot specify the rule for % based rollout with another matching condition.

The following is NOT supported by ConfigCat
IF tier = stripe
    THEN 30% = false 70% true

[easyCZ]

On the code level, implementing this should boil down to calling to the BillingMode service.

I believe we need to go through the service, because there is additional logic to determine the billing which is not self-contained elsewhere. This also introduces a dependency on another feature flag - isUsageBasedBillingEnabled and also introduces a dependency on Stripe (and may introduce dependency on Stripe's rate limit).

[geropl]

BTW here is a first attempt: #13138

[geropl]

Citing from the PR:

Instead of drilling this into BillingMode I opted for extending EntitlementService because it's a separate concern.
Still not super happy with the overhead we're creating, but want to unblock PVC.

We should really think about throwing it away afterwards. broom