chore: Update the hasql ecosystem deps to the upcoming releases

[nikita-volkov]

Updates to the latest developments in Hasql and its surrounding libs. Since they haven't been released yet, it comes with a set of cabal.project git-commit dependencies. Until these dependencies do get released (should be soon) I suggest to maintain this PR as a draft.

This PR heavily relies on another refactoring PR. To make reviewing easier I recommend first merging the refactoring.

cabal.project temporarily specifies GHC as 9.4 to ensure that the code works fine with it. It should be removed before merging.

[wolfgangwalther]

Please note that we feel very uneasy about the massive increase in Copilot use for hasql development recently. We are very likely not going to update beyond 1.9.3.1 and are considering to fork / vendor hasql instead at that version.

[nikita-volkov]

Wow. What's the issue with that?

[wolfgangwalther]

In the last 2 months, the hasql repository had changes in 160 files, 12,296 additions and 4,223 deletions. (compared master vs 1.9.3.1)

Compare that to the difference between 1.9.3.1 and 0.1.0.RC1 (the oldest tag): 73 files, 5,256 additions and 899 deletions. This development happened over a time of more than 10 years.

Do I question whether you, as the only human involved, are able to review the amount of 20 years of work in two months to ensure high quality? Yes, I do question that.

I really liked hasql - as well as your other projects and all the engineering work you put into that over the years. But the "new" hasql is not a product of your skills anymore, I don't trust the code and I have zero chance to review all these changes.

[nikita-volkov]

I understand your concern but I also see a bit of jumping to conclusions.

Have you looked at the amount of tests that's been added and how large a portion of the changed lines they occupy? It is the majority of those changes and the more tests we have, the more reliable the library is.

Have you considered the dead branches of Hasql with years of research and development put in? I also have a huge repository with an alternative to Hasql based on the native protocol, which I haven't even made public. What I release publicly is primarily the cumulative result of all of that. I have a vision for Hasql. I know how to incrementally improve it and I have a roadmap for that. This has nothing to do with LLMs.

I use LLMs to speed up by automating the dumb work. The design and all the essential code is still mine. Also it's still my reputation at stake, so there's no reason for me to lower my quality standards.

[nikita-volkov]

Thanks for your detailed response by the way! It certainly has given me a user-perspective which I haven't considered before.