Let ledger determine whether Shelley forecasting succeeds

[amesgen]

Description

Remove a pure exception in Shelley forecasting by letting the ledger determine whether a forecasting operation succeeds instead of reimplementing the stability window check manually.

Historically, it seems this was done this way as at, the slot we are forecasting from, was not simply the tip slot of the given ledger state as it is now, but rather an explicit argument:

https://github.com/input-output-hk/ouroboros-network/blob/0934a3cb1e24ecbfcbab4e40522d99ffcd60feaf/ouroboros-consensus-shelley/src/Ouroboros/Consensus/Shelley/Ledger/Ledger.hs#L322-L326

TODO Potential implications to (double)check:

• How fast does the Ledger short-circuit on failure?
• Do we need the new assert?
• Should we also assert that for < maxFor on success?
• Right now, there is no obvious function FutureLedgerViewError -> OutsideForecastRange, espc. as FutureLedgerViewError is backed by a (not statically guaranteed to be empty!) list. How desirable is it to change this?

Checklist

• Branch
  • Commit sequence broadly makes sense
  • Commits have useful messages
  • New tests are added if needed and existing tests are updated
  • If this branch changes Consensus and has any consequences for downstream repositories or end users, said changes must be documented in interface-CHANGELOG.md
  • If this branch changes Network and has any consequences for downstream repositories or end users, said changes must be documented in interface-CHANGELOG.md
  • If serialization changes, user-facing consequences (e.g. replay from genesis) are confirmed to be intentional.
• Pull Request
  • Self-reviewed the diff
  • Useful pull request description at least containing the following information:
    • What does this PR change?
    • Why these changes were needed?
    • How does this affect downstream repositories and/or end-users?
    • Which ticket does this PR close (if any)? If it does, is it linked?
  • Reviewer requested

[amesgen]

See #4146 (comment)