Support SlotNo <-> UTCTime conversions

[Anviking]

Context

⚠️ Ticket may be partly wrong. In the Shelley phase of Byron;Shelley, we have unlimited forecast range ⚠️

We currently have naive point -> time conversions that are going to break with the hard fork. We:

• Show the time transactions were inserted to the ledger
• Show the time of the next epoch
• Show the time of future changes to the delegation status

To help us, there will be a query from consensus that will enable us to do time conversions locally. We will
/not/ have to send one request per conversion. But we will have to update the conversion-info
from time to time. (I would guess some time per epoch.)

For the wallet the most annoying thing will be that you'll need to update this from time to
time, so you'd need some kind of stateful abstraction that if a conversion is out of range,
asks for an updated interpreter, tries again; if still out of date, throw an exception (this
would then be a bug in the wallet, trying to look ahead too far).

All answers are certain and not subject to rollback.

You get one of two answers: "Yes, I can convert this thing, here's the result [and it is not
subject to rollback]" or ‚"No, we don't know that yet".

Times of future epochs

We can convert historial times. There is a forecast range. We can know the time of the next epoch
start, but not anything beyond it.

So this will still work:

But we can no longer provide epochStartTime for changes to the delegation:

data ApiEpochInfo = ApiEpochInfo
    { epochNumber :: !(ApiT EpochNo)
    , epochStartTime :: !UTCTime
    } deriving (Eq, Generic, Show)

Luckily it seems Daedalus doesn't use it:

Sync progress

We can no longer convert the current wall clock to a slot while syncing. We are currently relying on this for the sync progress calculation. Doing the opposite however: converting the genesis and wallet slots to times, and comparing with the current time, should work. But perhaps not as well on jormungandr where there may be a large gap of empty slots between block0 and block1.

Decision

• Abstraction for point <-> UTCTime conversions for txs must be added Use SlotNo and TimeInterpreter #1901
• nextEpoch :: ApiEpochInfo field in ApiNetworkInformation should be kept
• Wallet delegation epochStartTime field should be removed
• Wallet syncProgress should be changed to compare wallet time vs wall time instead of wallet slot vs wall slot Use SlotNo and TimeInterpreter #1901

Acceptance Criteria

• ApiTransactions must show the correct insertedAt time
• The nextEpoch time must still be availible for Daedalus
• sync progress must not be broken

---

Development

• Fetch era summary via LSQ Cardano.Api -> Cardano.Api.Typed and HardForkBlock #1909, Improvements to slotting conversions / TimeInterpreter #1943, to ensure that EpochNo, SlotNo, and UTCTime conversions are done correctly, even after the fork.

QA

• Sync progress calculation changed in Properly support BlockHeader <-> HF.Point conversions #1868
• SlotNo, UTCTime, EpochNo conversions may fail if beyond the horizon of TimeInterpreter. When the node is syncing in Byron, the horizon is limited. In Shelley, it is unlimited.
• Existing integration tests verify that the behaviour is the same once in Shelley.
• In the Byron part of Byron;Shelley the network_tip and next_epoch is unknown if the node is unsynced, and will be omitted from the network information response. Also see QA section of GET http://localhost:8090/v2/network/information returns 500 on mainnet while wallet is syncing through Byron era. #1960. Extra test coming with Test getNetworkInformation handling of PastHorizonException #1977.
• Minor outstanding problem -> Listing transaction when node is still in the Byron era may fail with 500 #1971

[piotr-iohk]

lgtm.