Reconsider ledgerTipPoint

[mrBliss]

Quoting from #1505 (comment):

---

Also, I think that the idea of ledgerStatePoint is not correct. Say we have an empty ledger state with no applied blocks, so the last hash is GenesisHash. When we now "tick" it using a SlotNo s, which Point would we return? We can't return GenesisPoint, but we can't return BlockPoint either, because we don't have a hash.

A simple fix would be to return (WithOrigin SlotNo, ChainHash blk) instead of Point blk, but that would allow for (Origin, BlockHash h), which is an invalid combination. A new type would be better, e.g.:

data LedgerTip blk
  = NoAppliedBlock !(WithOrigin SlotNo)
    -- ^ No block has been applied to the ledger. When the ledger hasn't been
    -- \"ticked\", the argument will be 'Origin', otherwise, it will be @'At'
    -- slotNo@ where @slotNo@ is the ticked slot number.
  | AppliedBlock !(HeaderHash blk) !SlotNo
    -- ^ A block with the given hash has been applied. The 'SlotNo' will be
    -- that of the block, unless the ledger has been \"ticked\" with a more
    -- recent slot number.

[edsko]

Something related I've been thinking about: TickedLedgerState should really contain the slot number that it was ticked for. This would help in the Shelley integration also, as well as in some other places.

I wonder if we do that whether we could perhaps leave the semantics of the underlying LedgerState alone?

[nfrisby]

Last week (?) @edsko and I discussed a similar concern with the Mock ledger state that my WIP branch for Issue #1297 revealed. Synchronicity has struck: @mrBliss hypothesized something similar to explain Issue 1505 (hence this Issue) while @nc6 recently noticed similar issues with TPraos.

We all had a call just now. @edsko is fixing the bug (with a better fix than he and I originally came up with). I expect that the tests on my Issue 1297 branch will pass once I rebase it to include that fix. I will continue to debug Issue 1505 to determine if this Issue 1559 is indeed the underlying cause -- simply cherry-picking Edsko's fix might merely mask the repro since it depends on a race condition/subtle timing, so I want to understand its mechanics better.

Also, I should be able to rebase my PR for Issue 1489 onto this fix; Issue 1505 is the only remaining failure I've seen on that branch. Progress!