While doing that we pass stock changes to the service but we
lazy-evaluate them. This way we don't fetch all this data from DB when
it might not be used due to an early return.
Also, this makes it possible to save the stock-related logic for later.
Finally, when changing things to rely on `#initialize_order`'s boolean
return value I noticed though, that we were evaluating
`proxy_order.order` too early. When instantiating the service object it
won't exist yet.
The cart service and it's surrounding logic is a bit messy, as it jumps through hoops to add extra logic for the :max_quantity attribute used with the "group buy" feature.
This is the last bit of code where an order's line items could be changed where we were not using OrderContents.
This is a small semantic thing to clarify that we're not adding to / incrementing the quantity here, we're setting it to the given value. In other places where we change line items on an order we are actually adding the given value to the existing quantity.
`product.master` seems to always be `null` on
/api/v0/order_cycles/:id/products JSON response. That's because the
first of the underlying AR relation,
`order_cycle.variants_distributed_by(distributor)`, does not include
master variants. They are not in OC exchanges.
Previously we only set these part-way through deployment, so the values could be out of sync between our ENV vars and Spree::Config (which itself is a mix of both cached values and database-persisted values).
The state should have changed in the database if the payment was processed successfully, and the memoized version here will not know that without a reload.
If the page is reloaded after the payment has already gone through, we can skip the processing and give a non-error response; the payment is already completed and Stripe's response confirms it was successful.
When we're fetching the payment intent via PaymentIntentValidator in StripeSCA#purhcase (to capture it), we want it to fail loudly if it's not in "requires_capture" state. We're now also re-using the same PaymentIntentValidator service to check if payment processing was *successful*, in which case we need it *not* to fail loudly if the state == "succeeded", eg != "requires_capture".
