This fixes the error UK's is experiencing:
```
PG::AmbiguousColumn: ERROR: column reference "state" is ambiguous LINE
1: SELECT DISTINCT spree_orders.*, CASE WHEN state IN ('cancele...
^ : SELECT DISTINCT spree_orders.*, CASE WHEN state IN ('canceled',
'returned') THEN payment_total WHEN state IS NOT NULL THEN payment_total
- total ELSE 0 END AS balance_value, spree_orders.* FROM "spree_orders"
INNER JOIN "spree_shipments"
```
See
https://app.bugsnag.com/yaycode/openfoodnetwork-uk/errors/6058c45989d37300079e8312?event_id=6058ccd30075af73bcb20000&i=sk&m=nw.
This model concerns helps us put together this related methods. Although
it doesn't provide any encapsulation yet, it makes a bit easier to
consider them all next time we need to change this implementation
somehow. It's a bit of an illusion but it feels like we are making this
God object model a bit smaller.
It also gives more room for documentation that will aid future devs.
We rely now on the exhaustive list of states an order can be in after
checkout. What made this all a bit more messy is that I made up the
"checkout" order state, likely mixing it from the payment model states.
This simplifies things quite a bit and gives meaningful names to things.
Instead of relying on Spree::Order#outstanding_balance we make us of the
result set `balance_value` computed column. So, we ask PostgreSQL to
compute it instead of Ruby and then serialize it from that computed
column. That's a bit faster to compute that way and let's reuse logic.
We hide this new implementation under this features' toggle so it's only
used when enabled. We want hit the old behaviour by default.
