Reactivated gauges can't queue up rewards
Active gauges as set in `ERC20Gauges.addGauge()` function by authorised users get their rewards queued up in the `FlywheelGaugeRewards._queueRewards()` function. As part of it, their associated struct `QueuedRewards` updates its `storedCycle` value to the cycle in which they get queued up:\\n```\\ngaugeQueuedRewards[gauge] = QueuedRewards({\\n    priorCycleRewards: queuedRewards.priorCycleRewards + completedRewards,\\n    cycleRewards: uint112(nextRewards),\\n    storedCycle: currentCycle\\n});\\n```\\n\\nHowever, these gauges may be deactivated in `ERC20Gauges.removeGauge()`, and they will now be ignored in either `FlywheelGaugeRewards.queueRewardsForCycle()` or `FlywheelGaugeRewards.queueRewardsForCyclePaginated()` because both use `gaugeToken.gauges()` to get the set of gauges for which to queue up rewards for the cycle, and that only gives active gauges. Therefore, any updates `FlywheelGaugeRewards` makes to its state will not be done to deactivated gauges' `QueuedRewards` structs. In particular, the `gaugeCycle` contract state variable will keep advancing throughout its cycles, while `QueuedRewards.storedCycle` will retain its previously set value, which is the cycle where it was queued and not 0.\\nOnce reactivated later with at least 1 full cycle being done without it, it will produce issues. It will now be returned by `gaugeToken.gauges()` to be processed in either FlywheelGaugeRewards.queueRewardsForCycle()or `FlywheelGaugeRewards.queueRewardsForCyclePaginated()`, but, once the reactivated gauge is passed to `_queueRewards()`, it will fail an assert:\\n```\\nassert(queuedRewards.storedCycle == 0 || queuedRewards.storedCycle >= lastCycle);\\n```\\n\\nThis is because it already has a set value from the cycle it was processed in previously (i.e. storedCycle>0), and, since that cycle is at least 1 full cycle behind the state contract, it will also not pass the second condition `queuedRewards.storedCycle >= lastCycle`.\\nThe result is that this gauge is locked out of queuing up for rewards because `queuedRewards.storedCycle` is only synchronised with the contract's cycle later in `_queueRewards()` which will now always fail for this gauge.
Account for the reactivated gauges that previously went through the rewards queue process, such as introducing a separate flow for newly activated gauges. However, any changes such as removing the above mentioned `assert()` should be carefully validated for other downstream logic that may use the `QueuedRewards.storedCycle` value. Therefore, it is recommended to review the state transitions as opposed to only passing this specific check.
```\\ngaugeQueuedRewards[gauge] = QueuedRewards({\\n    priorCycleRewards: queuedRewards.priorCycleRewards + completedRewards,\\n    cycleRewards: uint112(nextRewards),\\n    storedCycle: currentCycle\\n});\\n```\\n