Store Stripe Customer ID internally, and make StripeService.findCustomerByAttributionId use the stored ID when available

[jankeromnes]

Is your feature request related to a problem? Please describe

This is a follow-up to #13002, but the bug was actually pre-existing:

• Sometimes (maybe around 1 in 10 times?) when you subscribe a team to Stripe, creating the subscription randomly fails:

• And in the backend, you'll see this error:

Error: No Stripe customer profile for 'team:123ff8cd-422f-4865-87eb-2d3767b2b16f'

• But if you try adding the same credit card / country / currency again, it works

This is because searching Stripe customers by attributionId seems a bit inconsistent right after customer creation (we poll Stripe Search to confirm that a new customer is available in search results, but then when running the same query a few seconds later, it might come up empty again).

Describe the behaviour you'd like

Instead of polling Stripe Search like we do here:

gitpod/components/server/ee/src/user/stripe-service.ts

Lines 94 to 101 in 759e588

	// Wait for the customer to show up in Stripe search results before proceeding
	let attempts = 0;
	while (!(await this.findCustomerByTeamId(team.id))) {
	await new Promise((resolve) => setTimeout(resolve, POLL_CREATED_CUSTOMER_INTERVAL_MS));
	if (++attempts > POLL_CREATED_CUSTOMER_MAX_ATTEMPTS) {
	throw new Error(`Could not confirm Stripe customer creation for team '${team.id}'`);
	}
	}

we should:

1. Store the created Customer ID in the team/user or their cost center (but it should not be widely accessible, because querying via attributionId is preferred)
2. When trying to find a customer by attributionId, StripeService.findCustomerByAttributionId should check for a stored ID first, and fall back to search of there is no ID, or the customer for that ID was deleted or its metadata were modified

Describe alternatives you've considered

• Accept that subscribing sometimes fails and needs to be retried once? 😬
• Wait for a few more seconds after polling Stripe Search? 😬

Additional context

[easyCZ]

Linking further context from internal discussion

[easyCZ]

Occurrence of this raised internally during Workspace Start - details

[easyCZ]

An initial draft of this is here

The draft chooses to store the (Stripe Customer ID, Attribution ID) tuple in a new table, independent of CostCenter but it can easily be changed to use it. The reason for storing it in a new table are the semantics of the CostCenter - new cost centers for an attribution get created but in the case of Stripe, the customer ID remains the same irrespective of the cost center.

Requests are proxied from server to usage, which handles the DB interaction.