Bogus TroveChange is added to the changelog of Troves upon capped liquidation

[danielattilasimon]

Query to demonstrate the issue:

{
  liquidation: troveChanges(
    where: {
      troveOperation: liquidateInRecoveryMode
      collateralRatioBefore_gt: 1
    }
    orderBy: sequenceNumber
    orderDirection: desc
    first: 1
  ) {
    trove {
      changes(
        orderBy: sequenceNumber
        orderDirection: desc
      ) {
        troveOperation
        collateralChange
        debtChange
      }
    }
  }
}

Which yields:

{
  "data": {
    "latestRecoveryModeLiquidation": [
      {
        "trove": {
          "changes": [
            // ...
            {
              "collateralChange": "-22.372070628947933783",
              "debtChange": "-40401.36361894997628",
              "troveOperation": "liquidateInRecoveryMode"
            },
            {
              "collateralChange": "-2.627929371052066217",
              "debtChange": "0",
              "troveOperation": "accrueRewards"            // <-- Bogus redistribution reward
            },
            {
              "collateralChange": "25",
              "debtChange": "40401.36361894997628",
              "troveOperation": "openTrove"
            }
          ]
        }
      }
    ]
  }
}

The accrueRewards operation is meant to represent liquidations shares received by Troves between 2 "proper" Trove operations (e.g. openTrove, adjustTrove, closeTrove, liquidateInNormalMode, ...)

So far there hasn't been a single liquidation by redistribution, so the above accrueRewards is clearly unjustified.

The issue was introduced when capped liquidations were added to the backend. Up until then, the _coll and _debt parameters of TroveLiquidated events reflected the final state of the Trove immediately before the liquidation. The subgraph relied on this to insert an accrueRewards operation in case there have been redistributions between the last Trove adjustment and the liquidation. However, in the case of a capped liquidation, _coll now reflects the capped portion of the collateral that's liquidated, so we can no longer rely on the event's parameters.

Instead, we should calculate the redistribution from the Trove's snapshots, stake and the global redistribution counters.