fix(subscriptions): on upgrade use correct invoice line

[StaberindeZA]

Because

• The incorrect next invoice date is shown in the subsequent invoice
  email
• For a subscription upgrade, the Stripe invoice can have a line item
  for the previous and current subscription. The existing logic assumes
  there is only one invoice line item.

This pull request

• Use the invoice line item with type "subscription" to determine the
  correct next invoice date.

Issue that this pull request solves

Closes: #12690

Checklist

Put an x in the boxes that apply

• My commit is GPG signed.
• If applicable, I have modified or added tests which pass locally.
• I have added necessary documentation (if appropriate).
• I have verified that my changes render correctly in RTL (if appropriate).

[biancadanforth]

Thanks Reino for digging into this. Your solution will definitely work, though I think we may want to throw an error if we don't find a type of subscription on any of the invoice.line_item objects?

As written, the current fallback is to use the period.end for an invoiceitem, which is the bug in this case.

[biancadanforth]

LGTM Reino thanks; one non-blocking suggestion for you based on other tests where we make assertions about errors.

[bbangert]

@StaberindeZA Ouch, this is going to be a problem elsewhere in our code most likely, because we have code in various places that still assume a single line item per subscription. I didn't know that they're both end up on a single subscription during an upgrade, we had assumed this would only occur when having multiple unrelated plans on a single subscription for billing alignment purposes.

[StaberindeZA]

@StaberindeZA Ouch, this is going to be a problem elsewhere in our code most likely, because we have code in various places that still assume a single line item per subscription. I didn't know that they're both end up on a single subscription during an upgrade, we had assumed this would only occur when having multiple unrelated plans on a single subscription for billing alignment purposes.

@bbangert thank you for calling it out. I was worried that might be the case. I'll take quick look through the code and will create a follow up ticket to fix the other occurrences.