[Usage-based] Attribute workspace instances on start

[jankeromnes]

Is your feature request related to a problem? Please describe

In the context of usage-based billing (#9036), we've identified that it's important to immediately "attribute" a workspace instance to a project, and to a "customer" (i.e. a Team or a User) when the instance starts.

This cannot be done asynchronously / later on, because any of these relationships from instance to project/customer can change at any time:

• Workspace (can be deleted)
• Project (can be deleted, can possibly change ownership in the future?)
• User (can be deleted, can join/leave teams, can upgrade/cancel)
• Team (can be deleted, can upgrade/cancel)

Thus, it's important to determine and persist the attributed final customer/account every time a workspace instance is started.

Describe the behaviour you'd like

Attribution can be determined in various ways:

• Workspace Instance → Workspace → Project? → Owner(User/Team)
• Workspace Instance → Workspace → Owner(User) (→ Team?)

Once determined on instance start, this information could be persisted:

• As new fields in d_b_workspace_instance (e.g. projectId?, plus userId? and/or teamId?)
• In a new database (e.g. a DB reserved for Usage accounting)

Describe alternatives you've considered

Additional context

[jankeromnes]

Another realization, the "attribution" information is more complex that just one field.

A workspace instance needs to be attributed to:

• A projectId (so that we can compute project usage)
• A userId (so that we know who created the instance, and the user can possibly be the final "customer" as well)
• A teamId (if a team is the "cost center" for this workspace instance, e.g. the team has enabled usage-based billing and the user has selected this team as their "cost center")
• Possibly, the user's or the team's Stripe customerId if there is one (if the usage is billed, i.e. not free credits, then this is the customerId to which we bill the usage -- can be a team or user, and can change if users/teams change their billing or get deleted) (EDIT: not needed, see below)

[easyCZ]

I believe that the attribution must work as an immutable record at the start of the workspace. We mostly need to know the unique ID (if a team, or individual) who has promised to pay for this workspace.

This information should be unrelated to Stripe as it would couple us to Stripe.

Related (internal) conversation.

[jankeromnes]

Overnight thought: the projectId and userId on the workspace (not the instance) might already be stable enough for Project and User attribution (provided they don't get deleted or anonymized when Projects/Users/Workspaces get deleted). That's because workspaces/instances can never change owners. (Instances can technically change projects, e.g. if you delete and recreate a protect but keep restarting the same workspace -- but maybe this is an edge case we can live with for now?)

If this is true, we might only need to store the "paying" teamId of an instance at start time (and if there is none, we know to bill the user).

[jankeromnes]

Great feedback from @svenefftinge -- rather than attributing to a Team (and defaulting to the owner User if there is no attributed Team), it would nicer to create a dedicated "Cost Center" object.

This would simplify the attribution model by making it more explicit (i.e. no implicit "Team or User if no Team" logic), and facilitate future attribution evolutions like:

• Attribute to a User explicitly
• Attribute to multiple Teams (e.g. have a shared Cost Center, or possibly set up "Organization" Billing for multiple Teams)

Cost Center would make sense for SaaS and also for Self-Hosted (i.e. to define various Cost Centers and map to internal structure, observe usage by Cost Center, or manage quotas, etc)