E.g.:
https://gitlab.iscpif.fr/gargantext/haskell-gargantext/-/jobs/18643

paginating QuantumComputing corpus works (MapTerms):            Fontconfig error: Cannot load default config file: No such file: (null)
Fontconfig error: No writable cache directories

Also, update Dockerfile with patched `nix.conf`

#483

Resolve "Error uploading zip file on dev"

See merge request !417

Fix bug in DB transaction rollbacks in the presence of domain-specific errors

Closes #480

See merge request !420

This commit fixes the bug with DbTx rollbacks and domain-specific
errors. What we do now is throwing an exception during the evaluation of
`DbFail`, to later catch it _after_ `withTransactionM` has performed a
clean rollback, and only at that point we call `throwError`.

This also means that we need to catch `DbTx` errors via the `MonadError`
interface, not via the exception-handling interface, to get proper
rollback behavior.

errorWith has a `HasNodeError` constraint but the name was misleading.

This means, of course, that now rollback tests are failing, but that's
fine, we can then fix things properly in the DbTx code.

Have `extractNgramsFromDocument` catch the right exception in case extraction fails

Closes #481

See merge request !419

[graphql] get contexts for ngrams fix

See merge request !416

Resolve "API refactorings"

See merge request !412

This described in this comment:
#477 (comment 14458)

I repaste, for history:

- job timeout was 30 seconds only and this is a big zip file, so the job timed out in worker
- however, this was recently added https://gitlab.iscpif.fr/gargantext/haskell-gargantext/blame/dev/src/Gargantext/Database/Action/Flow.hs#L490 and the timeout wasn't caught and the worker continued happily
- the job finished normally (most probably)
- the job was restarted, because default strategy for timeouts is to restart a job
- for sending files, we use postgres large objects because it keeps our JSONs small
- when the job finishes, it clears definitely the large object so that we don't leave large, unused blob data
- however, that job was restarted and there was no more a large object to work on
- you got some sql error, but that wasn't the root cause

Solution is:
- don't catch any exception, but be careful and handle `Timeout` or `KillWorkerSafely`
- increase job timeout for file upload
- change timeout strategy for file upload to `TSDelete`, i.e. don't retry that job anymore

It's possible that the zip file error was caused by a timeout (60 sec)
for zip file which is too low.

I think that sometimes, when user refreshed page, the websocket
connection could hang and the user stopped receiving new
notifications. This is modeled after CentralExchange timeout.

This fixes
#478
There was no `markStarted` and so 'remaining' was always at 0, so the
frontend thought the job was done, even though it was getting
notification about 'succeeded' in that job increasing

Separate ngram extraction from document insertion

Closes #473

See merge request !415

Now the tests pass again, but crucially `insertMasterDocs` runs in a
single atomic DB update, meaning we can rollback cleanly in case
disaster strikes.

The `ExtractNgrams` typeclass _definition_ imposed a redundant
`HasText` constraint, forcing all the _instances_ to have `HasText`
defined even though the instance didn't make any use of that.

That is overly-rigid, and it has been fixed by this commit.

This commit refactors the flow code to generate the ngrams for
the master docs separately, and then it "commits" them later after such
docs have been associated with a `Node`.