React to Zuora errors by fixing orders

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem

Orders within Subscription App are meant to be a 1:1 mapping to Zuora Subscriptions and be in sync.

However some times the orders and the subscription that originated them diverge, whether because the subscription was cancelled/refunded and our app was lacking the logic to react to that scenario or because the callouts from Zuora never happened or all failed, Zuora is down, Subscription App is down... (so many possibilities)

So although we can create better mechanisms to account for each of this origins (and we are and should continue to do so), these are two independent systems and keep them in sync is not possible:100:% of the time.

That is why we want to put up for consideration to proactively fix these sync gaps when those are uncovered.

By:
- Identifying a set of Zuora errors we get consistently.
- Set up corrective reactions within the Subscription App.

### :warning: Sync no more, soon...

Our final goal is to make Zuora the Single Source of Truth (SSoT) for CustomersDot and we want to keep that present and work towards that whenever possible. This translates into us writing any future code considering to actually rely on Zuora instead of reusing what is saved in `orders`. *Not only for this but all issues.*

[Transition to Zuora as the SSoT Epic](https://gitlab.com/groups/gitlab-org/-/epics/4664) will group all the effort to accomplish this, it aims "to reduce the data duplication in CustomerDot with Zuora and move us closer to calling Zuora the SSoT". This is a big effort and in the meanwhile we want to still alleviate some of sales blockers if possible and that is what this issue is about.

### What we want to solve

**SITUATION:** Customer is purchasing a .com plan for a namespace that has a refunded subscription associated to this.

**WHAT HAPPENS TODAY:** Customer is unable to proceed, contacts support, support deals manually with the order's state, support creates a ticket, the ticket is prioritized and ultimately an engineer will pick it up and try to find out the cause for this out of sync state (this cause is at this point not relevant, maybe the order is for a moment in time we didnt have logic to reset the order, maybe Zuora's profile was in silence mode, maybe callouts failed...) This is a lot of effort.

**WHAT THIS ISSUE PROPOSES:**
When Subscriptions App gets an error that **looks like the one for that **might** be related to this case, instead of raising right away and triggering all the response above, we can take a step to the side and:
- Attempt to fix! In this case: Query Zuora for the state of the subscription associated to the order
- **IF** it is cancelled
  - Reset the order's subscription data via `ProcessInactiveSubscriptionService`
  - Reattempt the user action (best case scenario customer purchased and it is happy)
- **ELSE** fail like we do today


### Result

By "closely" reacting to the identified (known) errors such as the one outlined and correcting the data we are saving a lot of time to support and removing many future duplicated issues that are created as a result.

Story points: 2.0