Refunded subscriptions cause customers to be unable to purchase

<!-- 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 
Often, when a subscription is refunded customers are unable to purchase again until we clear out the old `Order` object by setting the `subscription_id` and `product_rate_plan_id` to `nil`.

See: https://gitlab.com/gitlab-com/support/dotcom/dotcom-internal/issues/1663

Best guess as to how to reproduce:
- Purchase a new subscription
- Ask for a refund
- Attempt to re-purchase

### Proposal :pencil: 

@vshumilo writes: 

Based on the referenced tickets this happens in two main scenarios
1. The subscription is cancelled and the customer is not able tu purchase another subscription for the same group
1. The subscription is refunded and the customer is not able tu purchase CI minutes for it.

In order to address this, we will fix it in two separate MRs that correspond to the scenarios described above.

The main reason is that for the first scenario :one: the subscription portal currently listens for subscription callouts, so when a subscription is cancelled on the Zuora end we will get the callout and process it accordingly making it straightforward to recreate the fix.

For the second scenario :two: 
- A new `refund` endpoint needs to be created in the subscription portal
- Some `refund callouts` need to be configured on the Zuora Payment Notifications end
- Some questions need to be asked / answered to clarify the current refund process to establish what are the Zuora callouts we want to configure for refunds out of the available options (please see next section).
- Some investigation is in progress to establish how to get a Zuora Subscription based o a Zuora Refund
- Refunds and maybe some other objects need to be defined wihin the Subscription Portal to serve as an interface with the Zuora api. Ex: Refund is not one of the resources provided by IronBank

Based on this, we want to ship :ship: these scenarios separately to:
1. Deliver value in small incremental bits 
1. So the first part is not conditioned by the unknowns we have for the second

### Things we need to answer :question: 

1. What is the process to add a new callout to Zuora in Production mode
1. What are the current refunds that we handle, the 4 types available within Zuora notifications are:
    1. `Credit Balance Refund Processed | Credit Balance Refund Processed`
    1. `Credit Balance Refund Processed | External Credit Balance Refund Processed`
    1. `Payment Refund Processed | External Payment Refund Processed`
    1. `Payment Refund Processed | Payment Refund Processed`
1. How to get from the parameters available in the Zuora Refund (Payments scope) to the Zuora Subscription to be able to map the refund to an existing order (In Progress by @vshumilo)
1. How to get the type of Refund so we can differentiate between primary and secondary subscriptions (do not clear the subscription for the order if the refund is for ci minutes) (In Progress by @vshumilo)

### Thank you!

Shoutout to @rdavila for an awesome collaboration :handshake: and taking the time to talk through the challenges for the new endpoint and adding so much value and insight.

### The Promise :bulb: 

Document the process to add a new callout to Zuora (if it is not already)

### Result

### Next steps (if any)

### How will we measure success?

Story points: 3.0