feat: handle payment error on trial

[jono-booth]

Description:
Add a description of your changes here.

Jira:
ENT-10761

Merge checklist:

• ./manage.py makemigrations has been run
  • Note: This must be run if you modified any models.
    • It may or may not make a migration depending on exactly what you modified, but it should still be run.

Post merge:

• Ensure that your changes went out to the stage instance
• Deploy to prod instance

[iloveagent57]

One possible area for improvement:
As written, this will make two API calls, but we could make it only 1 with something like this:

all_enterprise_subscriptions = client.list_subscriptions(enterprise_uuid)
current_plans, other_plans = [], []
for sub in all_enterprise_subscriptions:
    if sub.get('is_current'):
        current_plans.append(sub)
    else:
        other_plans.append(sub)
if not current_plans:
    return
current_plan_uuid = str(current_plan.get('uuid'))
future_plans = future_plans_of_current(current_plan_uuid, other_plans)

[jono-booth]

Thanks @iloveagent57, makes sense. I still have a bit of clean up work to do.

I just wanted to get the PR up so I could get your input on the email task. You mentioned you were looking into a wrapper for Braze, which seems a bit overkill. Seeing as the emails tend to have different logic it makes sense to keep the logic separate for each. But in this case the 2 functions are very similar.

Do you prefer I:
A) Keep the duplication
B) DRY up just these methods in this class
C) Look at a better wrapper solution for this and other emails

[iloveagent57]

Ah, I see what you're saying. Yeah, wrapper might be overkill. If there's easy/obvious opportunities to DRY stuff up, go ahead and do that, otherwise don't worry about it.

[pwnage101]

[request] Add an else block to this with logger.warn("cancellation code branch reached, but handler not yet implemented.")

[pwnage101]

This approach exposes us to liability because it is sensitive to any future change we might make to allow multiple current SubscriptionPlans to exist aside from the stripe-managed one, or any change to allow multiple Stripe Subscriptions per customer. I'd recommend taking into account some other data to join to make sure the plans being deactivated are somehow related to the stripe Subscription.

I don't have a tested recommendation, but maybe there's something you can do with the CheckoutIntent. E.g. get the CheckoutIntent ID from the subscription object, then get the subscription plan lineage from the CheckoutIntent record.

[jono-booth]

@pwnage101 I've got a few merge conflicts around this function, I need to use it too just to set the status and reason. Any reason you have explicit arguments inside the current function on main? I normally exclude any logic from the update function and keep it more loosely coupled and have a single responsibility.

FYI, I have not merged your most recent work yet, you've release more changes on Friday since my last rebase.

[iloveagent57]

FWIW, I would change the signature and logic of the update payload to accomodate this like so:

def update_subscription_plan(self, subscription_uuid, salesforce_opportunity_line_item=None, **kwargs):
    payload = {**kwargs)
    if salesforce_opportunity_line_item:
        payload['salesforce_opportunity_line_item'] = salesforce_opportunity_line_item