RPC tests are broken

[alexfmpe]

When trying to consume the output of /block I hit the following error

<interactive>: parseTimeOrError: no parse of "2024-05-02T01:47:36.734781Z"
CallStack (from HasCallStack):
  error, called at libraries/time/lib/Data/Time/Format/Parse.hs:124:15 in time-1.12.2:Data.Time.Format.Parse

this is triggered by https://github.com/f-o-a-m/kepler/blob/6c1ad7f37683f509c2f1660e3561062307d3056b/hs-abci-types/src/Network/ABCI/Types/Messages/FieldTypes.hs#L109-L110

the root problem seems to be trying to parse a length of time when the field is actually a timestamp

ghci> parseTimeOrError True defaultTimeLocale "%FT%T%QZ" "2024-05-02T01:47:36.734781Z" :: UTCTime
2024-05-02 01:47:36.734781 UTC

ghci> parseTimeOrError True defaultTimeLocale "%FT%T%QZ" "2024-05-02T01:47:36.734781Z" :: DiffTime 
*** Exception: parseTimeOrError: no parse of "2024-05-02T01:47:36.734781Z"
CallStack (from HasCallStack):
  error, called at libraries/time/lib/Data/Time/Format/Parse.hs:124:15 in time-1.12.2:Data.Time.Format.Parse

Confusingly, the test suite suggests this endpoint is actually working properly https://github.com/f-o-a-m/kepler/blob/6c1ad7f37683f509c2f1660e3561062307d3056b/hs-tendermint-client/kv-test/KVStore/Test/KVSpec.hs#L44-L47

but if we add a print result we correctly get

Failures:
  (...)
  libraries/time/lib/Data/Time/Format/Parse.hs:124:15: 
  2) KVStore.Test.KV, Tendermint KV Store - via hs-tendermint-client, Can query /block and parse the result
       uncaught exception: ErrorCall
       parseTimeOrError: no parse of "2024-05-02T19:19:06.123194Z"
       CallStack (from HasCallStack):
         error, called at libraries/time/lib/Data/Time/Format/Parse.hs:124:15 in time-1.12.2:Data.Time.Format.Parse

it seems like we're not fully forcing the Success value in https://github.com/f-o-a-m/kepler/blob/6c1ad7f37683f509c2f1660e3561062307d3056b/hs-tendermint-client/src/Network/Tendermint/Client/Internal/RPCClient.hs#L174-L178 so this blows up in client code eventually.

The tests definitely should be dealing with the normal form of the value but I'm not sure what the lib should be doing, given this can only be a problem when using unsafe code.

The current behavior preserves laziness but leads to unsafe code having unexpected behavior, which suggests a need for a strict option, even if less performant when the entire value isn't needed. In which case, that could replace the current behavior or exist alongside it.

To avoid duplicating every endpoint, maybe results could be wrapped in a newtype that users then need to choose to "run" lazily or strictly so a conscious choice is made every time?

EDIT: corrected the source of the excessive laziness issue