For some reason, cabal 3.4.1.0 builds w/o the assistant and webapp,
even when the flag is explicitly turned on. Moving the build-depends from
inside the if flag section to the main build-depends somehow fixes this.

Since the webapp build deps are thus always available, there is no reason
not to build the webapp when building the assistant. So, got rid of the
webapp build flag. Kept the assistant build flag for now, since building
without it does at least still speed up the build.

Sponsored-by: Brock Spratlen on Patreon

This reverts commit b5dc0409.

Broke windows build, because the new lts updates Win32 to a version that
lacks a function that git-annex needs. git-annex.cabal depends on an
older Win32, and so stack build fails.

Will need to wait to update stack.yaml until this is fixed
https://github.com/haskell/win32/issues/208
and is in a new LTS release.

This has not been needed since stack <1.4.0, and even the i386ancent
build uses stack 2.1.1.

Stack 2.7.5 seems to have forgotten about this old config and warns
about it, so this avoids that warning.

The libtinfo-dev was added to the docs at the same time, I assume it is
also not necessary.

Last try at this broke on windows with a problem installing ghc, but I
wanted to try again.

Also this has a version of aws that allows using aeson 2.0, which has a
potential security fix.

This reverts commit d2bc2683.

That seemed to break building on windows, before it starts building
git-annex at all, it tried to install ghc and something blew up:

Processing archive: C:\Users\runneradmin\AppData\Local\Programs\stack\x86_64-windows\ghc-9.0.2.tar.xz
Extracting  ghc-9.0.2.tar
...
Extracted total of 11790 files from ghc-9.0.2.tar
C:\Users\runneradmin\AppData\Local\Programs\stack\x86_64-windows\ghc-9.0.2-tmp-6d0fbe7f3b29e56c\ghc-9.0.2\: renameDirectory:pathIsDirectory:CreateFile "\\\\?\\C:\\Users\\runneradmin\\AppData\\Local\\Programs\\stack\\x86_64-windows\\ghc-9.0.2-tmp-6d0fbe7f3b29e56c\\ghc-9.0.2\\": does not exist (The system cannot find the file specified.)

Hopefully a newer ghc version or updated stackage version will fix this
at some point, in the meantime revert it.

Did not intend for 02ef3d6a to
disable them.

The webapp modules cannot build with the assistant disabled, so make the
webapp be under the assistant build flag.

Sponsored-by: Jarkko Kniivilä on Patreon

Debian stable and the i386ancient build both have a new enough network
to not need this flag any longer.

Sponsored-by: Svenne Krap on Patreon

Removed vendored copy of http-client-restricted, and removed the
HttpClientRestricted build flag that avoided that dependency.

http-client-restricted is in Debian stable, and the i386ancient build also
uses it, so I think this vendored copy is no longer needed.

Sponsored-by: Noam Kremen on Patreon

ghc 8.10

Only turning it off when the criterion library is not installed.

Not enabled for osx or i386ancient yet since that will need some
invesitgation to update their respective stack.yaml files.

So these special remotes are always supported.

IIRC these build flags were added because the dep chains were a bit too
long, or perhaps because the libraries were not available in Debian stable,
or something like that. That was long ago, those reasons no longer apply,
and users get confused when builtin special remotes are not available, so
it seems best to remove the build flags now.

If this does cause a problem it can be reverted of course..

This commit was sponsored by Jochen Bartl on Patreon.

Needs stack version 2.3 to build, which has only recently made it into
debian unstable.

This commit was sponsored by Jake Vosloo on Patreon.

In stack-lts-12.14.yaml, there were dep issues using the new libraries,
which may not be resolvable with those old versions. Didn't check, just
disabled using the libraries there, which will hold us for a couple
years.

(It would probably be easy enough to relax some of the dep versions in
http-client-restricted and git-lfs to the older versions.)

Otherwise use the vendored copy as before.

The library is in Debian testing but not stable. Once it reaches
stable, the vendored copy can be removed.

Did not add it to debian/control because IIRC that's used to build
git-annex on stable too, possibly. However, the Debian maintainer will
probably want to make the package depend on libghc-http-client-restricted-dev

This commit was sponsored by Ilya Shlyakhter on Patreon.

Otherwise use the vendored copy as before.

The library is in Debian testing but not stable. Once it reaches
stable, the vendored copy can be removed.

Did not add it to debian/control because IIRC that's used to build
git-annex on stable too, possibly. However, the Debian maintainer will
probably want to make the package depend on libghc-git-lfs-dev.

This commit was sponsored by Ilya Shlyakhter on Patreon.

cabal needs to support the old one for debian currently, but stack can
require the newer one

This reverts commit 75c40279.

Debian unstable is one version too old, so this can be de-reverted in a
bit.

Behavior should be the same, but I'd hope to eventually get rid of
most of Utility.FileSystemEncoding and this is a first step.

git-annex find is now RawFilePath end to end, no string conversions.
So is git-annex get when it does not need to get anything.
So this is a major milestone on optimisation.

Benchmarks indicate around 30% speedup in both commands.

Probably many other performance improvements. All or nearly all places
where a file is statted use RawFilePath now.

part of the hacking in 067aabdd
but did not need to be committed

Finally builds (oh the agoncy of making it build), but still very
unmergable, only Command.Find is included and lots of stuff is badly
hacked to make it compile.

Benchmarking vs master, this git-annex find is significantly faster!
Specifically:

	num files	old	new	speedup
	48500		4.77	3.73	28%
	12500		1.36	1.02	66%
	20		0.075	0.074	0% (so startup time is unchanged)

That's without really finishing the optimization. Things still to do:

* Eliminate all the fromRawFilePath, toRawFilePath, encodeBS,
  decodeBS conversions.
* Use versions of IO actions like getFileStatus that take a RawFilePath.
* Eliminate some Data.ByteString.Lazy.toStrict, which is a slow copy.
* Use ByteString for parsing git config to speed up startup.

It's likely several of those will speed up git-annex find further.
And other commands will certianly benefit even more.

Build with silently-1.2.5.1 on Windows; the old one used "NUL" which is not supported with recent versions of ghc.

hopefully fixes a windows build problem

13.27 failed on OSX:

Undefined symbols for architecture x86_64:
"_utimensat", referenced from:
_c7zP_info in libHSunix-2.7.2.2.a(Files.o)

Which seems likely to be a compilation problem?

The latter should not be needed as this lts version includes Win32.

The cabal file does not yet demand this version because it's not in Debian
yet and only affects use of certian broken http servers, but let's use it
when it's easily available.

* S3: Support enabling bucket versioning when built with aws-0.21.1.
* stack.yaml: Build with aws-0.21.1

Like with the network-uri split, cabal will automatically turn off the flag
when building with an old network.

I have not tested building with the new network-3.0.0.0 yet; several
other dependencies including aws are still pinned on network-2.*

And added stack-lts-9.9.yaml to support old versions of stack.
The i386 ancient autobuilder needs stack-lts-9.9.yaml; the OSX autobuilder
may also use it for a while, and it's needed to build on eg debian stable.

Using the method described in
https://www.fpcomplete.com/blog/2018/05/pinpointing-deadlocks-in-haskell
but my own code to implement it, and with callstacks added.

This work is supported by the NIH-funded NICEMAN (ReproNim TR&D3) project.