This keeps the `OrderBalance` abstraction but removes the old code now
that the feature is enabled for all users in all instances and there are
no bugs reported. It's become dead code.
This makes it possible to deploy it without releasing it to users since
the toggle is not enabled for anyone.
It aims to make the balance calculation consistent across pages.
We only care about non-cart orders and skipping carts, saves PostgreSQL
query planner to go through thousands of records in production use cases
(my food hub).
We go from
```sql
-> Index Scan using index_spree_orders_on_customer_id on spree_orders (cost=0.42..12049.45 rows=152002 width=15) (actual time=0.015..11.703 rows=13867 loops=1)
```
to
```sql
-> Index Scan using index_spree_orders_on_customer_id on spree_orders (cost=0.42..12429.46 rows=10802 width=15) (actual time=0.025..17.705 rows=9954 loops=1)
```
It's simpler and many orders of magnitude more efficient to ask the DB
to aggregate the customer balance based on their orders. It removes
a nasty N+1.
The resulting SQL query is:
```sql
SELECT customers.*, SUM(spree_orders.total - spree_orders.payment_total) AS balance
FROM "customers"
INNER JOIN "spree_orders"
ON "spree_orders"."customer_id" = "customers"."id"
WHERE "customers"."enterprise_id" = 1
AND (completed_at IS NOT NULL)
AND (state != 'canceled')
GROUP BY customers.id
ORDER BY email;
```
The scope for customersCtrl did not have access to the sorting
preferences stored in the nested ColumnsCtrl scope. To address this,
the page has been changed to use a new set of sorting preferences
declared in the customersCtrl scope itself.
Also, these sorting preferences are now stored in an object. This
enables the parent scope to see changes to the sorting preferences which
are done via the nested ColumnsCtrl scope,
The "Bulk Order Management" page is also affected by the same scoping
issue. Once this page is fixed, we can remove remnants of the sorting
preferences initialized in ColumnsCtrl.
It seems that the success message on the customers page is disappearing before the spec can
detect it. This seems unlikely since it's present for 3 s, but this is my best theory right now.
