Update semaphore-compat to 2.0.0.0 to fix #9993

[wz1000]

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
  • Is the change significant? If so, remember to add significance: significant in the changelog file.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

Update to semaphore-compat 2.0.0 fixing #9993 and https://gitlab.haskell.org/ghc/ghc/-/issues/25087

semaphore-compat now uses a unix sockets based implementation.

Semaphore identifiers are now versioned, and we can really on the versioning
scheme to detect semaphore version mismatch with GHC and fallback gracefully if
possible.

GHC patch: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/15729

After the GHC patch lands, it will include a "Semaphore version" field in its
settings file/--info output that we can use to guide Cabal behaviour.

If this field does not exist (and ghc is 9.8+), then we assume it uses version v1 of the protocol
and this triggers a graceful degradation of behaviour to -jN without semaphore based coordination.

See also

semaphore-compat MR: https://gitlab.haskell.org/ghc/semaphore-compat/-/merge_requests/8
ghc-proposals change: ghc-proposals/ghc-proposals#673

[geekosaur]

This needs to be added to the other project files as well, or perhaps imported from project-cabal/ghc-options.config or one of the other imports. In particular, cabal.validate.project will need it for CI.

We may also need a warning somewhere that HEAD relies on an unreleased package when this goes in.

[philderbeast]

I don't know if we have a common place to put source-repository-package yet. Maybe create and import a new file, project-cabal/deps-external.config¹ or project-cabal/external-pkgs.config or project-cabal/source-deps.config.

Footnotes

1. That's the name I went with in Updo. ↩

[Bodigrim]

Is there a reason semaphore-compat-2.0 cannot be released though? It would save a lot of pain not to deal with source-repository-package here.

[geekosaur]

My assumption is that there's a bit of a dependency loop here and a cabal build using it is needed to test it fully before release. And it's relatively less painful to use source-repository-package in cabal than to make Hadrian use it.

[geekosaur]

Correction: for ghc it's just a pinned submodule. Testing it before release still requires the cabal equivalent (source-repository-package) on our side.

[wz1000]

The source-repository-package is temporary, I will drop it once we release semaphore-compat 2.0. I intend to do this before this PR is merged.