This function allows us to keep only the roots, and discard the
redundant children after building a 'Forest'.

I think we can use the NgramsTree and NgramsForest types to our
advantage for the 'searchTableNgrams' & co, so I have revamped that
module to put it to good use.

This commit changes the implementation of filterNgramsNodes to not
filter too aggressively nodes that are present in a path.

This causes a test failure that needs to be investigated.

[openalex] make search act similar to the one on openalex web

See merge request !425

Port all the tasty specs to hspec

See merge request !423

See #490

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.