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`.

706 dev graph parameters display

See merge request !407

Fix a bug in `buildPatterns` and friends

Closes #395

See merge request !413

The final `T` doesn't add anything. It also moves the `HasText`
constraint _outside_ the typeclass definition.

Update IGraph

See merge request !411

Fixes a bug in the implementation of `buildPatterns`. In particular,
when we are building a `Pattern`, we need to do so in a case insenstive
fashion, otherwise later in the call to `replaceTerms` we would be
calling this from `extractTermsWithList` that cast everything into
lowercase due to the use of `monoTextsBySentence`.

This means that before this commit if we tried to search "Map" into
the text "Map is what I use when I'm lost" we wouldn't get a match,
because the latter would be converted into lowercase first
(i.e. "map is what i use when i'm lost") and we were trying to look
for the string "Map" (i.e. the former) into the transformer, yielding
no matches.

Previously the generator was generating all sorts of unicode symbols,
which doesn't play well for things like tab separators, carriage returns
and other things.

Furthermore, we need to be careful to not use the same symbol set of
`isSep` when we generate terms, because we are simulating an ngrams
search in a document and ngrams do not contain those separators
(i.e. `k2(` is not a valid ngram, but `k2` is).

Our IGraph library was updated to fix [this issue](haskell-igraph#5).

The `filterNodes` function's name and type signature were confusing, so
they were changed to make it evident that the filtering function for an
antry is applied to its total number of cooccurrences.

Reduce code duplication and simplify a few things.

The changes in this commit were made without relying on any knowledge
about what the code means or does; the changes should be understandable
even without knowing the project.

There's a filter in place to not show nodes not connected to any other
node, however the strict inequality was also filtering out nodes
connected to exactly one other node.

Removed some dead code, renamed some stuff, made exports explicit

Spinglass functions would output incoherent clusters when the input graph
was nonconnected.

`occurrencesWith` takes a function parameter to map over the input
collection before counting occurrences. Every time it's called, though,
it's with `identity`, so I replaced the function with a basic occurence
counting function.

Note that if one needs to apply a function to a collection before counting
occurrences, they can simply `fmap` over the collection first.

Port (almost all) DB operations in GGTX to use the transaction API

Closes #466

See merge request !408

The refactored DB API now has a separate building block to create an Opaleye query that
counts the number of returned results; we do that via `countRows`, exactly like the previous version.

However, I have discovered a small footgun in the Opaleye API -- if you have
two `Select` statements both calling countRows in a chain, that will always yield a value of 1,
because the inner `countRows` will give you the actual number of results by returning
a single row with an integer inside (i.e. the count).

However, the subsequent (outer) call to `countRows` will return the number of rows
of the previous step .. which is always going to be one!

The bug was that I had left somewhere the spurious `countRows` in the query which
would return the number of documents needed for the TFICF field, triggering the bug
(because then we had `it` ALWAYS equal to 1.0).

In the new API, while we cannot prevent the bug at the type level we can
easily do an audit by grepping for `countRows`, making sure we have exactly one instance,
i.e. inside `mkOpaCountQuery`.