The cancellation happens async in Javascript. Therefore we need to wait
for and outcome on the page to know that the action finished. The
expectation needs to be around that whole block.
We actually want only one job enqueued if the same backorder is
affected. Time to fix that.
Update every single order line to reflect local orders and stock levels.
New cases supported:
* Add lines for orders created by an admin.
* Create backorder line after increase of local line item quantity.
* Adjust local stock after variant has been removed from order cycle.
`Spree::OrderContents#update_or_create` is used to update the cart when
on the /shop page. If you start an order and proceed to the "Order
summary" step, and then decide to update your order by using the shop
link next to the cart, such update wouldn't update the shipment.
This result in the order page in the backoffice displaying the wrong data,
and more importantly, in the stock not being updated.
So now we ensure shipment will be updated, which result in the checkout
flow being restarted, thus making sure the shipment is updated.
I couldn't fix it easily. But I also think that the testing approach had
low value here.
It raised:
```
Failures:
1) Map map can load does not show alert
Failure/Error:
assert_raises(Capybara::ModalNotFound) do
accept_alert { visit '/map' }
end
Minitest::Assertion:
Capybara::ModalNotFound expected but nothing was raised.
[Screenshot Image]: /home/runner/work/openfoodnetwork/openfoodnetwork/tmp/capybara/screenshots/failures_r_spec_example_groups_map_map_can_load_does_not_show_alert_64.png
# ./spec/system/consumer/map_spec.rb:11:in `block (3 levels) in <top (required)>'
# ./spec/system/support/cuprite_setup.rb:39:in `block (2 levels) in <top (required)>'
# ./spec/base_spec_helper.rb:153:in `block (3 levels) in <main>'
# ./spec/base_spec_helper.rb:153:in `block (2 levels) in <main>'
```
A Vine voucher is really a specific type of FlatRate voucher but because
a Vine voucher can be used by mutiple enterprise, it can be considered
different enough to warrant it's own class.
It still share a lot of the behaviour of a FlatRate voucher, so to avoid
duplication, all the shared functionality have been moved to a
Vouchers::FlatRatable concern.
