timeToEpochEnd calculates backwards, breaking protocol math
When a lien is liquidated, it calls `timeToEpochEnd()` to determine if a liquidation accountant should be deployed and we should adjust the protocol math to expect payment in a future epoch. Because of an error in the implementation, all liquidations that will pay out in the current epoch are set up as future epoch liquidations.\\nThe `liquidate()` function performs the following check to determine if it should set up the liquidation to be paid out in a future epoch:\\n```\\nif (PublicVault(owner).timeToEpochEnd() <= COLLATERAL_TOKEN.auctionWindow())\\n```\\n\\nThis check expects that `timeToEpochEnd()` will return the time until the epoch is over. However, the implementation gets this backwards:\\n```\\nfunction timeToEpochEnd() public view returns (uint256) {\\n  uint256 epochEnd = START() + ((currentEpoch + 1) * EPOCH_LENGTH());\\n\\n  if (epochEnd >= block.timestamp) {\\n    return uint256(0);\\n  }\\n\\n  return block.timestamp - epochEnd;\\n}\\n```\\n\\nIf `epochEnd >= block.timestamp`, that means that there IS remaining time in the epoch, and it should perform the calculation to return `epochEnd - block.timestamp`. In the opposite case, where `epochEnd <= block.timestamp`, it should return zero.\\nThe result is that the function returns 0 for any epoch that isn't over. Since `0 < COLLATERAL_TOKEN.auctionWindow())`, all liquidated liens will trigger a liquidation accountant and the rest of the accounting for future epoch withdrawals.
Fix the `timeToEpochEnd()` function so it calculates the remaining time properly:\\n```\\nfunction timeToEpochEnd() public view returns (uint256) {\\n  uint256 epochEnd = START() + ((currentEpoch + 1) * EPOCH_LENGTH());\\n\\n  if (epochEnd <= block.timestamp) {\\n    return uint256(0);\\n  }\\n\\n  return epochEnd - block.timestamp; //\\n}\\n```\\n
Accounting for a future epoch withdrawal causes a number of inconsistencies in the protocol's math, the impact of which vary depending on the situation. As a few examples:\\nIt calls `decreaseEpochLienCount()`. This has the effect of artificially lowering the number of liens in the epoch, which will cause the final liens paid off in the epoch to revert (and will let us process the epoch earlier than intended).\\nIt sets the payee of the lien to the liquidation accountant, which will pay out according to the withdrawal ratio (whereas all funds should be staying in the vault).\\nIt calls `increaseLiquidationsExpectedAtBoundary()`, which can throw off the math when processing the epoch.
```\\nif (PublicVault(owner).timeToEpochEnd() <= COLLATERAL_TOKEN.auctionWindow())\\n```\\n