EntitlementService Usage-Based Pricing

[geropl]

Description

Based on: #11814

1. Introduce EntitlementServiceUBP
   • TODO: Implement hasPaidSubscription: 55c01f7#diff-fd2c4594d5bd9aa04668bdce9e9c810d3c495192a0be434006c7181f4853260bR93
2. Implement BillingService.checkSpendingLimitReached (based on usage until Implement BillingService.GetLatestInvoice #11692 got merged)#
3. Wiring, re-use of BillingService (commit)

Related Issue(s)

Fixes #11402

How to test

Actually, after #11814 has been tested thoroughly, this can be tested in prod by enableing isUsageBasedPricingEnabled, and testing the rollout flow. 🙃

Release Notes

NONE

Documentation

Werft options:

• /werft with-preview
• /werft with-payment

[geropl]

@jankeromnes @AlexTugarev This should build now. Can be moved to "ready for review" after #11814 has been merged, and this PR has been rebased on that! 👍

[AlexTugarev]

Got a inversify dependency cycle on

Server 
--> GithubApp 
--> PrebuildManager 
--> WorkspaceStarter 
--> WorkspaceManagerClientProvider 
--> WorkspaceManagerClientProviderCompositeSource 
--> Symbol(WorkspaceManagerClientProviderSource) 
--> Symbol(WorkspaceManagerClientProviderSource)

which seems to be unrelated to this PR changes on first look. Quickly checked with current main's state to rule out issues from there, and updated once more.
Not sure, if that comes from the multiInject thing (which happens to cause headaches sometimes) or a subtle change of imports which also causes module to be loaded differently.

[AlexTugarev]

/werft run

👍 started the job as gitpod-build-gpl-ets-ubb.5
(with .werft/ from main)

[AlexTugarev]

'Wasted 1h of debugging in the wrong direction. Turns out the problematic import is import { BillingService } from "./billing-service", which is completely unrelated to the above mentioned cycle reported by inversify.

Ah, EntitlementServiceUBP -> BillingService -> UserService -> EntitlementService is the bogus path. Actually, UserService does not use EntitlementService at all.

[jankeromnes]

Note: As currently implemented, it reads like everyone on Usage-Based gets XL workspaces.

[jankeromnes]

Problematic situation:

• I have a personal Chargebee plan + a legacy Chargebee team plan
• I also have a team that has Usage-Based enabled

In the team, I'm able to view the Usage-Based UI (e.g. Usage, Billing), but if I click on upgrade, the credit card form does not show up.

That's because the API methods getStripePublishableKey and getStripeSetupIntentClientSecret get rejected for my user, because my user is still in Chargebee mode (technically, these calls are made on behalf of a team that has Usage-Based enabled, but we're not sending through the teamId because it's not needed).

Possible solutions:

• Display a proper error message in the UI (e.g. "You need to cancel all your personal Chargebee plans before you can upgrade a team to Usage-Based")
• Authorize anyone to make the calls getStripePublishableKey (get the publicly-readable Gitpod front-end key) and getStripeSetupIntentClientSecret (create a session that allows you to submit credit card details)

[jankeromnes]

Ok, thanks @geropl and @AlexTugarev for completing this big work item.

The code looks good to me, and after testing it, it seems that all the Chargebee flows work as well as before (with one slight worry about the out-of-hour situation).

Approving so that this lands, and so that we can test all the recent changes together on staging before they go live tomorrow morning. 🤞

Allegory of this PR: 💣🛹 (a skateboard that makes me nervous 😅)