Description of problem:
It is possible for the cp_pool.quantity_consumed value to be a different value compared to the sum of all the entitlement consumed values for that pool. This remains even after a refresh.

In prod, we encountered this error when a customer couldn't attach to a pool because the limit was reached, even though the customer knew that couldn't be the case. Double-checking showed this to be the case: quantity_consumed = 3, but the actual consumed value was 2.


Version-Release number of selected component (if applicable):
2.2.3


How reproducible:
Rare.


Steps to Reproduce:
1. Can't reproduce it yet, but it is possible to find cases where this has already happened. Query: 

SELECT calc.owner_id,
       calc.quantity,
       calc.stated_consumed,
       calc.actual_consumed
FROM  (SELECT p.id                AS owner_id,
              p.quantity          AS quantity,
              p.quantity_consumed AS stated_consumed,
              c.actual_consumed   AS actual_consumed
       FROM   cp_pool p
              JOIN (SELECT pool_id,
                           COALESCE(Sum(e.quantity), 0) actual_consumed
                    FROM   cp_entitlement e
                    WHERE  e.owner_id IN (SELECT id
                                          FROM   cp_owner)
                    GROUP  BY pool_id) c
                ON p.id = c.pool_id
       WHERE  p.owner_id IN (SELECT id
                             FROM   cp_owner)) calc
WHERE  calc.stated_consumed <> calc.actual_consumed; 


Actual results:
Some pools state they are consuming a value different than what they are actually consuming.


Expected results:
cp_pool.quantity_consumed equals the sum of all the entitlements consumed amounts for that pool.

Additional info:

Research from the Candlepin team has found that the calculation for this field is lost due to lack of @Transactional annotation.