IO functions for reading. Remove PoolMetadataFile type

[newhoggy]

Description

Add IO functions for reading files.
Remove PoolMetadataFile type and use File type instead.
Work around some type-inference issues that shouldn't exist.

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• New tests are added if needed and existing tests are updated. These may include:
  • golden tests
  • property tests
  • roundtrip tests
  • integration tests
    See Runnings tests for more details
• Any changes are noted in the CHANGELOG.md for affected package
• The version bounds in .cabal files are updated
• CI passes. See note on CI. The following CI checks are required:
  • Code is linted with hlint. See .github/workflows/check-hlint.yml to get the hlint version
  • Code is formatted with stylish-haskell. See .github/workflows/stylish-haskell.yml to get the stylish-haskell version
  • Code builds on Linux, MacOS and Windows for ghc-8.10.7 and ghc-9.2.7
• Self-reviewed the diff

Note on CI

If your PR is from a fork, the necessary CI jobs won't trigger automatically for security reasons.
You will need to get someone with write privileges. Please contact IOG node developers to do this
for you.

[newhoggy]

This can't be () because we wan't to use the functions for reading things with e other than ().

The fact that e is here at all is problematic. e is for decode errors, but why should functions purely used for reading and writing files and do no decode at all have to concern themselves with decode errors? Having the e here produce type-inference problems down the line.

See #5194 (comment)

[newhoggy]

The compiler needs to infer a concrete type for e because it "needs" to display the error. The compile doesn't actually need the display the error because the constructor that has e is never used, but the compiler doesn't know that. We have to help the compiler by fixing e = () because there is an Error () instance this work.

It's unpleasant we have to help the compiler infer a type to display an error that never gets displayed, but our errors are tightly coupled.

[carbolymer]

Tbh, a typeclass would work here better instead of having all those specialized functions.

[newhoggy]

I don't have an objection to type classes.

You're welcome to put up a PR and we can see what it looks like.

[carbolymer]

data FileError e = FileError FilePath e
                 | FileErrorTempFile
                     FilePath
                     -- ^ Target path
                     FilePath
                     -- ^ Temporary path
                     Handle
                 | FileIOError FilePath IOException
  deriving (Show, Eq, Functor)

Firstly, do we really need to have a type parameter in FileError for explicit errors for files? This seems overly specific and unnecessary for just error handling. This type parameter also does not make much sense for constructors which do not carry a value of type e and requires plugging with something like (), which is painful, like @newhoggy mentions.

My suggestion here would be to go similarly to https://hackage.haskell.org/package/base-4.18.0.0/docs/Control-Exception.html : remove type parameter, and make type existential and provide access to the field value via existing Error class. And in the rare need for handling particular error type returned, we could just simply cast and handle it. What do you think?

[newhoggy]

These are the types of e that are currently used and we have Error instances for them:

CardanoAddressSigningKeyConversionError
IOException
InputDecodeError
JsonDecodeError
ScriptDecodeError
TextEnvelopeCddlError
TextEnvelopeError

We need to be able to throw these error types along side File ones because functions exist that produce both kinds of errors.

This is another example of where oops helps.

The purely file functions can throw FileError, purely decode functions can throw DecodeError and functions that do both can throw them side-by-side:

readByteStringFile :: ()
  => e `CouldBe` FileError
  => File content In
  -> ExceptT (Variant e) IO ByteString

decodeMyType :: ()
  => e `CouldBe` DecodeError
  => ByteString
  -> ExceptT (Variant e) IO MyType

readFileAndDecodeMyType :: ()
  => e `CouldBe` FileError
  => e `CouldBe` DecodeError
  => File MyType In
  => ByteString
  -> ExceptT (Variant e) IO MyType
readFileAndDecodeMyType file = readByteStringFile file >>= decodeMyType

Full separation of concerns. We don't have to:

• invent new error types to contain other error types
• find a module to put those types in and debate where they should go
• translate between error types because functions to marshal them through functions because we can only throw one error type at a time
• couple different kinds of errors and make functions declare errors that are never thrown
• catch errors with constructors that are never thrown
• write code for things that never happen.

[Jimbo4350]

LGTM