Assertion failure in long-range HFC ticking

[amesgen]

Consider ticking an ExtLedgerState of a HardForkBlock across an era/epoch boundary where the tip slot is more than one safe zone before the era/epoch boundary. This is currently (current main, ie 0dc2699) triggering an assertion failure (concretely, ticking from 133531000 to 133660800 across the Conway HF):

CallStack (from HasCallStack):
  error, called at src/ouroboros-consensus/Ouroboros/Consensus/Util/Assert.hs:11:30 in ouroboros-consensus-0.20.1.0-inplace:Ouroboros.Consensus.Util.Assert
  assertWithMsg, called at src/ouroboros-consensus/Ouroboros/Consensus/HardFork/History/Util.hs:32:38 in ouroboros-consensus-0.20.1.0-inplace:Ouroboros.Consensus.HardFork.History.Util
  countSlots, called at src/ouroboros-consensus/Ouroboros/Consensus/HardFork/History/Summary.hs:130:25 in ouroboros-consensus-0.20.1.0-inplace:Ouroboros.Consensus.HardFork.History.Summary
  slotToEpochBound, called at src/ouroboros-consensus/Ouroboros/Consensus/HardFork/Combinator/State/Infra.hs:254:15 in ouroboros-consensus-0.20.1.0-inplace:Ouroboros.Consensus.HardFork.Combinator.State.Infra
  applySafeZone, called at src/ouroboros-consensus/Ouroboros/Consensus/HardFork/Combinator/State/Infra.hs:222:29 in ouroboros-consensus-0.20.1.0-inplace:Ouroboros.Consensus.HardFork.Combinator.State.Infra
  reconstructSummary, called at src/ouroboros-consensus/Ouroboros/Consensus/HardFork/Combinator/State.hs:167:7 in ouroboros-consensus-0.20.1.0-inplace:Ouroboros.Consensus.HardFork.Combinator.State
  epochInfoPrecomputedTransitionInfo, called at src/ouroboros-consensus/Ouroboros/Consensus/HardFork/Combinator/Protocol.hs:192:12 in ouroboros-consensus-0.20.1.0-inplace:Ouroboros.Consensus.HardFork.Combinator.Protocol

(I added some HasCallStack constraints for this)

Note that this happens as part of ticking to tick the protocol state, after the ledger state has already been ticked.

We should think more about such "long-range" HFC ticking and properly document whether we do (not) expect it to work, and point this out in the code.

---

This luckily isn't relevent for the current node as we never perform such long-range ticks: Both sources of new blocks (ChainSync/BlockFetch and forging) first require forecasting to the target slot, which only succeeds within a safe zone, so any subsequent tick won't be a long-range tick.