Adapt cabal build to lts-20.26

[jneira]

• Since the recent upgrade of main stack build to lts-20.22 , the default constraints of cabal solver (get the newer versions) makes the build fail

• This pr adds the required constraints, got from https://www.stackage.org/lts-20.22

• It also ignores deprecations for unison-share-projects-api cause getting a working version of jose package is very difficult only touching cabal.project due to package revisions

• Tested manually with cabal build all --project-file .\contrib\cabal.project -w ghc-9.2.8

• Building with ghc-8.10.7 fails with:

[ 6 of 34] Compiling Unison.Position  ( src\Unison\Position.hs, D:\dev\ws\haskell\unison\dist-newstyle\build\x86_64-windows\ghc-8.10.7\unison-core1-0.0.0\build\Unison\Position.o )

src\Unison\Sqlite\Sql.hs:404:3: error:
    • Variable not in scope:
        asum
          :: [State.StateT [Lump] (Megaparsec.Parsec Void Text) Fragment]
             -> P Fragment
    • Perhaps you meant one of these:
        ‘sum’ (imported from Prelude),
        ‘msum’ (imported from Unison.Prelude)
    |
404 |   asum
    |   ^^^^

i think it would be not too difficult to workaround that error but i guess that build is unsupported, so 🤷

[aryairani]

@jneira Hey thanks for the update. We are actually on lts-20.26 now; does that change anything?

[jneira]

I don't think so, I only checked the lts versions to help to discover the needed version bounds in cabal.project and they have not changed afaics

[aryairani]

lgtm

[aryairani]

@jneira Actually could you just add

{-# GHC_OPTIONS -Wno-deprecations #-}

to unison-share-projects-api/src/Unison/Share/API/Hash.hs instead of hiding deprecation warnings globally.

At first I was thinking it was fine as-is and we can get the deprecated call removed quickly; but just to be safe, I'd rather minimize the scope of the hidden warnings.

[jneira]

@aryairani sure, that was my firts idea but i was not sure if touching a source file only due to a temporary package bound was a good one.

If we think about what will happen when the stack build reach the jose version with derecations:

• if it is only set for cabal we will hit it in stack and we will have to fix it for sure
• if we set it for the file maybe we will miss the deprecation warning and it could be not be fixed

But as you consider, both alternatives have caveats (as usual 😝)

[aryairani]

@jneira Oof, I see. I was a little mixed up and didn't notice that the deprecation warning was only set in cabal.project; I assumed it was set in stack.yaml, which could then lead to even more missed deprecation warnings.

I will ask @mitchellwrosen or @tstat to weigh in, but I guess it's fine with me as-is in this case.

I also added #4212 to try to stop using Crypto.JWT.addClaim, although I think since we're an application and not a widely used library, that pinning specific dependency versions is probably the better fix for us than even having a range, which I suppose is what Stack LTS does.