Some important logic happens after the order transition from one state
to another. In particular, voucher are recalculated. To fix any
inconsistency, we make sure the order is the state matching the checkout
step we are on.
I wrongly assumed that `voucher.create_adjustment` would return nil
if failing to create an adjustment. I will in fact return an
adjustment object with errors.
The voucher apply button is inside form that has another a submit button,
it leads to a weird situation where either one will submit the whole
payments page form. Adding a named parameter on the voucher apply button
means we can distinguish between the two by checking for the presence
of params[:apply_voucher].
Refactor split checkout to use the new controller. But unfortunately
we can't have nested form, so adding a voucher is still handled by
SplitCheckoutController.
The split checkout page uses `mrujs` and `CableCar` to set the form as
a remote one and perform `CableCar` operation if any : https://mrujs.com/how-tos/integrate-cablecar
The previous solution broke the cart handled by angularJS, it looks like
`morpdom` (https://mrujs.com/references/remote-forms-and-links Navigation Adapter section )
was doing something that angularJS didn't like when redirecting to
the current page.
With the power of `CableCar`, we now replace the #voucher-section on the
split checkout page instead of doing a redirect.
The checkout payment step will also show a warning.
The amount used is stored in the adjustment created, so we will be able
to track how much has been used down the line.
If a feature is activated or not depends on the database which is reset
after each test scenario. So enabling a feature doesn't leak into other
scenarios.
Just enabling the feature is less code and more realistic than mocking a
method call.
