Investigate why some orders and customers do not have a zuora_account_id

## Purpose

It was discovered that some orders in CustomersDot production do not have a `zuora_account`.  This is expected for some orders like trials and orders that revert to the free plan.  After filtering those out, there are still some orders (around 22 at the time of writing this) where `zuora_account_id` is nil.

Similarly, there are some customers attached to orders that do not have a `zuora_account_id` either.  There are even more customers without `zuora_account_id` than orders mentioned above.  

Please see the detailed comment referenced below for more info.  It would be good to figure out why this has happened, whether it is a problem, and if so, provide a solution.

## Follow-up

The following discussion is from !2985:

- [ ] @tyleramos made the [comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/2985#note_537877774):

    > @lulalala Thanks for raising this as a concern! This will indeed be a problem.
    > 
    > I've done some investigation into our production data and there are many orders where `zuora_account_id` is nil. However, for `Order#current_subscription`, it's actually the `customer.zuora_account_id` that needs to be present. It looks like [this method](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/6e353a98934a4878a07843e08605a1fdfcb8c9b2/app/models/subscription.rb#L37) doesn't actually use the `zuora_account_id` on the order itself. The same concern exists thought that `customer.zuora_acocunt_id` could be `nil`. In fact, I think the situation is actually a little worse because we use `customer.zuora_account_id`, but more on that in a bit.
    > 
    > Let's breakdown the orders where `order.zuora_account_id` is nil a bit:
    > 
    > ```
    > irb(main):001:0> Order.count
    > => 156049
    > irb(main):002:0> Order.where(zuora_account_id: nil).count
    > => 111447
    > ```
    > 
    > Out of 156049 total orders, 111447 do not have `zuora_account_id` so that seems bad. But once we filter out trials, and trials that reverted back to the free plan, it looks much better.
    > 
    > ```
    > irb(main):034:0> Order.where(zuora_account_id: nil).where(trial: false).where.not(product_rate_plan_id: 'free-plan-id').count
    > => 22
    > ```
    > 
    > So really only 22 orders that could be a problem. I didn't dig into these too much but it seems like they could be trials that didn't transition to non-trials correctly. Either way, this is a much smaller, manageable number. I might open an issue to determine if these need to be addressed.
    > 
    > Circling back to the fact that `order.current_subscription`, and `order.subscription` for that matter, use `customer.zuora_account_id`. There are even more orders that aren't trial or free plan where the `customer.zuora_account_id` is nil.
    > 
    > ```
    > irb(main):054:0> Order.left_outer_joins(:customer).where(customers: { zuora_account_id: nil }, trial: false).where.not(product_rate_plan_id: 'free-plan-id').count
    > => 265
    > ```
    > 
    > Of these 265 orders, 48 of them are managed by resellers because the `login_activated` attr is false.
    > 
    > ```
    > irb(main):060:0> Order.left_outer_joins(:customer).where(customers: { zuora_account_id: nil, login_activated: false }, trial: false).where.not(product_rate_plan_id: 'free-plan-id').count
    > => 48
    > ```
    > 
    > The remaining 217 orders are still mysterious. After spot checking the papertrail for a few, it looks like the customer.zuora_account_id was set but previously, but removed by gitlab admins. It would be good to understand why this is done. The bigger question though is should update the subscription methods in Order to use `order.zuora_account_id` instead of `customer.zuora_account_id` as this might be less error prone?
    > 
    > **TLDR:** I'm fine with your approach in this MR to add an early return. I'm also wondering if it's worth logging the event that we don't create the cloud license for this reason. At least to begin with we could log it as an error. If it turns out, it's really common and acceptable, then we can update it to log as info. I'll open up follow-up issues for the other problems identified. :sweat_smile:

Story points: 2.0