bump nixpkgs for hls 1.4.0.0

[smatting]

This PR bumps nixpkgs to a commit that includes Haskell Language Server 1.4.0.0

In its current state wire-message-proto-lens fails to build with error

$ cabal build wire-message-proto-lens
...
/nix/store/hp8wcylqr14hrrpqap4wdrwzq092wfln-glibc-2.32-37/lib/libc.so.6: version `GLIBC_2.33' not found (required by /nix/store/lw2br602v3sijay0z5xqvkkgpnmbbl4s-wire-server-compile-deps/lib/libncursesw.so.6)

This is due to the fact that cabal is wrapped (see cabal-wrapper in dev-packages.nix) which sets env vars LD_LIBRARY_PATH. When this wrapper calls protoc during building the protoc inherits these env vars which causes this error. If you build wire-message-proto-lens with the unwrapped cabal binary

/nix/store/23w1rh354pidr4pwa190k0n7j6hk1xqx-cabal-install-3.6.2.0/bin/cabal cabal build wire-message-proto-lens

this succeeds.
One solution to fix this issue could be to wrap protoc itself which clears the env vars before running.

Checklist

• The PR Title explains the impact of the change.
• The PR description provides context as to why the change should occur and what the code contributes to that effect. This could also be a link to a JIRA ticket or a Github issue, if there is one.
• If HTTP endpoint paths have been added or renamed, the endpoint / config-flag checklist (see Wire-employee only backend wiki page) has been followed.
• If a cassandra schema migration has been added, I ran make git-add-cassandra-schema to update the cassandra schema documentation.
• changelog.d contains the following bits of information (details):
  • A file with the changelog entry in one or more suitable sub-sections. The sub-sections are marked by directories inside changelog.d.
  • If new config options introduced: added usage description under docs/reference/config-options.md
  • If new config options introduced: recommended measures to be taken by on-premise instance operators.
  • If a cassandra schema migration is backwards incompatible (see also these docs), measures to be taken by on-premise instance operators are explained.
  • If a data migration (not schema migration) introduced: measures to be taken by on-premise instance operators.
  • If public end-points have been changed or added: does nginz need un upgrade?
  • If internal end-points have been added or changed: which services have to be deployed in a specific order?

[sysvinit]

I've tried building wire-server-proto-lens myself on my own system, and I see the same error which @smatting did initially, however I think I might know why this happens. In the failing build, I saw the following output in the terminal:

callProcess: /nix/store/lw2br602v3sijay0z5xqvkkgpnmbbl4s-wire-server-compile-deps/bin/protoc "--plugin=protoc-gen-haskell=/srv/scratch/nosnap/cabal/store/ghc-8.8.4/proto-lens-protoc-0.7.0.0-e-proto-lens-protoc-b8929e427a1578e508a5f1b7931b3ae94d8955f27d5b653ae90033205a96f77f/bin/proto-lens-protoc" "--haskell_out=/tmp/protoc-out-ce15025eae6c39f0" "--proto_path=generic-message-proto/proto" "generic-message-proto/proto/otr.proto" (exit 1): failed

This implies that the nixpkgs-provided version of protoc is trying to load a plugin which was built and installed by cabal. I nuked my cabal directory (on my laptop this is /srv/scratch/nosnap/cabal; by default it's ~/.cabal) and tried to build again, and the build succeeded.

My theory for why this happens is that the Haskell protoc plugin binary was built before I moved from building with stack to building with cabal. I'm guessing that the old binary was built with ghc from stackage, and linked against system libraries on my (Debian) laptop. This binary is incompatible with the libraries in nixpkgs, which are being loaded due to LD_LIBRARY_PATH being set in the cabal wrapper script. Zapping the cabal directory and starting again means that the protoc plugin is rebuilt, this time against nixpkgs ghc, which means that the protoc plugin starts up and runs correctly.

@smatting can you reproduce this? That is, does the build of wire-server-proto-lens work for you if you start with a fresh cabal directory?

Edit: I think the reason invoking cabal directly without the wrapper works correctly is that LD_LIBRARY_PATH isn't set, which means that existing versions of the plugin binary can find the appropriate system libraries correctly.

[smatting]

Closing this in favor of #1852
We found out that protoc binary in the cabal cache was not being rebuilt with the new environemnt. ldd shows that the this binary linked to a different glibc version than the bumped environment which caused the issues.
Removing the proto-lens-protoc directory from the cabal cache forced a rebuild and solved the problem.