Port all the tasty specs to hspec

See merge request !423

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 can be derived from 'url' setting already.

This is used mainly to specify at which port the server will listen.

The 'url' param is the external URL (sometimes it's needed for the
server to know where it is hosted, e.g. when sending out emails).

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