Track the Marketplace order status

### Background:

**NOTE**: ATM we only have one Marketplace partner, which is `Arrowsphere`. So the below description uses `Arrow` to describe the scenario. However, this scenario applies to all Marketplace orders. It does not limit to Arrow.

Previously Arrow system talks to Gitlab Platypus API endpoint(and then Platypus talks to CustomersDot). We will remove Platypus in this communication chain.

* previously(as of today): `Arrow -> Platypus -> CustomersDot`
* after removing Platypus, Arrow will directly talk to CustomersDot: `Arrow -> CustomersDot`

In order to achieve this, there are several changes required on CustomersDot side.

1. implement OAuth provider in CustomersDot. This allows secure API access control. We propose to use `doorkeeper` gem.
1. add required data mapping in CustomersDot. This maps some Arrow payload data to the CustomersDot/Zuora/SFDC required values.
1. track the Arrow order status. The status is used to:  allow Arrow to poll the order status; validate duplicate requests; ensure to take action safely only on the right order status.
1. provide API endpoint for Arrow to poll the order status.

For more information, refer to the task breakdown at https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/4637#note_1062429151.

### This issue's scope

This issue covers the thrid task `track the Arrow order status`

#### Proposal

Create a table `MarketplaceOrders`(columns: `external_subscription_source, external_subscription_id, payload, status(:creating, :failed, :created, :provisioned)`. This has the benefit to prevent duplicated API requests from Arrow.

* An Arrow create order request comes
* If there is a validation error, return failure without tracking this order.
* Check the existence of `external_subscription_id`/`external_subscription_source`. 
   * If does not exists, create new `marketplace_orders` record for this `external_subscription_id`/`external_subscription_source`, and mark the status as `:creating`. Continue
   * If exists and the status is `:failed`, reset the order(status to `:creating`, payload to new payload). Continue.
   * If exists and the status is not `:failed`, return duplicated order error.
* Start to create the customer/subscription/order/sfdc..
* If the CDot failed to create the subscription, mark the status as `failed`
* When customer/subscription/order are created, mark status as `:created`
* After notify_customer(this is currently in ZuoracallbackWorker), mark the status as `:provisioned`.

#### Where does the `check duplicate marketplace order` sit in the process flow.
**NOTE**: this is a simplified flowchart. It does not contain some steps like `map payload`, `check Visual compliance`, `check customer existance`. We could also consider all of these as part of the general `create subscription` node.

```mermaid
graph TD
    A(Start) -->|POST order request received| B[Authentication]
    B --> C{Authenticated?}
    C -->|No| D(Reject request)
    C -->|Yes| E[Validate payload]
    E --> F{valid payload?}
    F -->|No| D
    F -->|Yes| G[check existing order record]
    G --> H{order exists?}
    H -->|No| L[Create order record]
    L --> I[Create subscription]
    H -->|Yes|J{existing order failed?}
    J -->|No| D
    J -->|Yes| K[Reset order status]
    K --> I
    
```

#### State transition diagram
```mermaid
stateDiagram-v2
    [*] --> creating
    creating --> created: Customer/Order/ZuoraSubscription created
    creating --> failed: Encounter error
    failed --> creating: Receive the order request again
    created --> provisioned: Customer notification sent
    provisioned --> [*]
            
```
### Problem

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

### Result

### Next steps (if any)

### How will we measure success?

Story points: 3.0