[Free connectors] create enrollment modal

[ambirdsall]

Part of #21074. Clicking on the enrollment CTA banners (i.e. #21222 or #21223) triggers a modal. The modal's content explains the program and enrollment requirements (i.e. registering future-billable payment info) in more detail, and it contains the CTA button which actually sends users to the stripe connect setup flow. For airbyte employees, a Figma mockup can be found here; it looks like this

Users enter the stripe connect setup flow via an internal url expects to be given a successUrl and cancelUrl parameter and will set up the slack session and redirect the user. For now, the success and cancel urls should be the user's current url with distinct query params appended (e.g. ?freeConnectorProgramEnrollment=success or ?freeConnectorProgramEnrollment=cancel).

[ambirdsall]

@pmossman, I'd like to have a quick check-in on the handoffs between browsers, servers, and stripe. As I understand it, the current plan is: frontend (user clicks "enroll now!") -> backend (accepts success/cancel urls from FE, creates stripe session, redirects user) -> stripe (user either completes or cancels connect setup flow in Stripe) -> frontend (user is redirected by Stripe to the success or cancel url as appropriate). My mental map is missing the part where the backend receives the ID for the newly-registered payment method, but it also seems to me that the backend can handle that in a way that is completely transparent to the frontend code. So: is there anything the frontend should do differently or in addition to what's sketched out above in order to properly kick off an enrollment?

[pmossman]

@ambirdsall that sketch is accurate! The backend receives the newly-created stripe customer ID from a webhook that fires from Stripe roughly in parallel with the success redirect.

Now that you raise this, I'm realizing there could be a sort of race condition where the user is redirected back to Airbyte before the webhook event is processed and before we've had a chance to write a new record to the UserPaymentAccount table in the webhook handler. I can think of a few ways to maybe address such a race condition:

1. Probably the most involved and robust solution would be to set the successUrl to some intermediate backend endpoint that immediately persists something that marks the enrollment as 'PENDING' while we await the webhook, and then the free_connector_program_info endpoint could read what we persist to tell the front-end to hide the call to action. This intermediate endpoint could then redirect the user to the intended front-end destination.
2. Much smaller but more fragile/gross would be to set some sort of URL param on the successUrl that the front-end looks for to set some temporary state that hides the call to action until the free_connector_program_info endpoint is returning the correct response

Not sure if there's a middleground between those options, what do you think of all of that?