refactor: webhooks-based approach

[iuioiua]

Previously, newly created OAuth users weren't registered as Stripe customers, so their subscriptions couldn't be managed.

This change adds a webhook endpoint for Stripe. When a user's subscription is renewed or cancelled, /api/subscription is called, making a corresponding change to the status of the subscription in the customers table in Supabase.

This PR also includes other minor cleanups, fixes and tweaks.

#19 is a prerequisite for this PR.

[iuioiua]

@thorwebdev, is there any chance you'd be able to have a quick look over this? Is this an improvement in design?

[thorwebdev]

Looks great overall, good stuff! \o/

Regarding the usage of Database webhooks to create stripe customer objects. Definitely a valid approach, but alternatively you might want to consider to create the Stripe customer object on the fly the first time it is needed.

[iuioiua]

Excellent suggestion! I've gone full circle and reverted webhooks for functionality relating to the customers table, and now it's looking much simpler. Thank you.

PTAL, @thorwebdev.

[iuioiua]

I think there'd be fewer moving parts if stripe_customer_id and is_subscribed were stored in the user's metadata object rather than a customers table. WDYT?

[iuioiua]

I'll go ahead and merge for now. We can evolve these ideas later.

[thorwebdev]

Sorry for the delay. Yes, LGTM 👍 just added one note above regarding using createOrGetCustomer in the middleware.