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.
