Deactivate unpaid orders when buying new pricing or changing plan

[rdlabspl]

In example project i can do as follows:

1. Create new order for buying additional 10 days of my current plan and not pay for it.
2. Create new order for changing plan and pay for it. Then my plan is changed for another one.
3. Go to order list and select first order, and then pay for it with fake payments. As a result code with comment This should not ever happen (as this case should be managed by plan change request) but just in case we consider a case when user has a different plan changes account's expiration date and plan for the first one.

Solution:
All orders with status NEW should be marked as CANCELED when we create new order or change plan without creating new order.

I can create PR for this.

[rdlabspl]

@cdvv7788 , @sebastian-code, what do you think about this?

[sebastian-code]

I do agree with the main concept, but think than perhaps that's not the best workflow; I think than a new order can work as a quote, and in the same way can expire after a determined time, and not directly. What do you think? It's actually a very raw concept for me because I haven't given it enough though.

[rdlabspl]

If I understood correctly, you propose to expire unpaid orders after determined time.
I don't think that it's a good idea, because it doesn't solve problem I described on the top of this post.
The problem is fact that user can create an order, and pay for it after making some other actions, after which this order doesn't make much sense, that's why we want to prevent user from paying for old orders.
Do we have any argument for allowing user to have more that one Order to pay at the same time?

[sebastian-code]

Like I said before, is still a very raw concept mainly because I don't know how the package is used out there today, is there someone with a use case where somehow the customer has multiple plans at the same time? Which business cases are being solved using this package?

Perhaps you're right and I'm overthinking the use case; I still believe we should cover a wider scenario, but at this point there is no evidence than someone is using the package outside the use case you describe, maybe in the future so let's cross that bridge when we get there.

If @cdvv7788 has no other opinion, perhaps we can go with your PR to the package.