For some reason the order objects were stale here when calling order.update! from either a payment or shipment callback, which was overwriting those states as nil on the order.
This new class lets us [Branch by
abstraction](https://www.martinfowler.com/bliki/BranchByAbstraction.html)
by encapsulating an order's balance. As a result, that's the only place
where we need to check the feature toggle, instead of every place where
`#outstanding_balance` is called (quite some). That would be very hard
to review and it'd be more likely to introduce bugs.
What I like about this is that we also managed to group together the
data and logic that we had spread in a few places and have it nicely
encapsulated. So, where we had a number, we'll now have an object.
Once we fully change all `#outstanding_balance` consumers to use this
new abstraction we'll be able to remove the methods this class replaces.
These are: `Spree::Order#outstanding_balance?`,
`Spree::Order#display_oustanding_balance` and
`OrderHelper.outstanding_balance_label`.
This is just the first step. I'll follow this up with a PR per
page/mailer/whatever where we use the balance to replace it with an
instance of `OrderBalance`. That is, splitting up what I explored in
https://github.com/openfoodfoundation/openfoodnetwork/pull/6959 but in
very small and manageable pieces.
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.
The custom RSpec matchers they use raises the following deprecation
warning
```
Using `stub` from rspec-mocks' old `:should` syntax without explicitly enabling the syntax is deprecated. Use the new `:expect` syntax or explicitly enable `:should` instead. Called from /home/runner/work/openfoodnetwork/openfoodnetwork/spec/support/matchers/delegate_matchers.rb:22:in `block (2 levels) in <top (required)>'.
```
It's not worth maintaining those matchers to test such
implementation-related thing. Whether or not any delegations work is
something that will be caught by integration tests or directly stubbing
the collaborator object's methods.
This stems from
https://github.com/openfoodfoundation/openfoodnetwork/pull/6902.
Increases the maximum number of digits (on the left side of the decimal place) that the column can hold, to allow larger values. This change is made in Spree 2.2 and is relevant in cases with either large order values, or certain currencies that have large values as standard. For example, 100 UK Pounds is roughly 4000 Thai Baht. 1 million pounds is unlikely to ever be needed as a value, but 1 million Baht is not so unlikely...
