Refactor: Remove (mis)uses of GHC.Show instances

[monacoremo]

This is an item on our refactoring roadmap #1804

Using GHC.Show to pretty-print or serialize data is an anti-pattern, show is meant to create a Haskell expression that can be parsed by read, see https://hackage.haskell.org/package/base-4.16.0.0/docs/GHC-Show.html

This PR removes all uses of GHC.Show instances in the codebase. As a side effect, this avoids several string conversions, especially when parsing preference headers, for what is likely a small performance gain.

[wolfgangwalther]

I think I get the reasoning for not using GHC.Show.

But are there any reasons against using custom classes for this purpose?

Just two examples from the first commit (preferences):

• Why not one ToAppliedHeader class for both resolutionAppliedHeader and transactionAppliedHeader?
• Why not one ToHeaderValue class for all of resolutionStr, representationStr, parametersStr, countStr, transactionStr?

I think this would make it a bit more concise and clearly show that those functions mentioned above all share a common goal / output.

[monacoremo]

I think this would make it a bit more concise and clearly show that those functions mentioned above all share a common goal / output.

True, that's a bit cleaner! I tried to keep it as simple as possible in general, but it makes sense to use typeclasses in this case.

Edit: see latest commit with those changes for Preferences. We should do something similar for dumpConfig, but that's for another PR!

[wolfgangwalther]

Edit: see latest commit with those changes for Preferences.

I Like that!

We should do something similar for dumpConfig, but that's for another PR!

Agreed. This could be something like ToConfigValue and should include showTxEnd and the other showXXX functions we currently have. Maybe we could even extend this class to cover some of the builtin types that we use for other config options. The class could then include the quoting etc...

And then there should be a class for ToSqlFragment. I'm sure we will find "a few" other cases where using that would make things consistent.

[monacoremo]

Many thanks for reviewing @wolfgangwalther ! The FreeBSD build is doing weird things again due to some cache issues, but otherwise this should be good to merge