Add protection against failure to reserve jobs

[Raveline]

WIP

[Raveline]

All right, this version works for a wrong query in the consumers. Here is an example by adding a non existing column:

  "error": "DBException {dbeQueryContext = SQL \"UPDATE chargebee_tasks SET   reserved_by = <16> , attempts = CASE     WHEN finished_at IS NULL THEN attempts + 1     ELSE 1   END WHERE id = ANY( <Array1 []> ) RETURNING id, event, attempts, surprise_surprise\", dbeBackendPid = 500778, dbeError = DetailedQueryError {qeSeverity = \"ERROR\", qeErrorCode = UndefinedColumn, qeMessagePrimary = \"column \\\"surprise_surprise\\\" does not exist\", qeMessageDetail = Nothing, qeMessageHint = Nothing, qeStatementPosition = Just 181, qeInternalPosition = Nothing, qeInternalQuery = Nothing, qeContext = Nothing, qeSourceFile = Just \"parse_relation.c\", qeSourceLine = Just 3651, qeSourceFunction = Just \"errorMissingColumn\"}, dbeCallStack = [(\"runPreparedSQL\",SrcLoc {srcLocPackage = \"consumers-2.3.4.0-83af746950b8f91e9e93ca91ee357d2eb6bad519fa73eb8edc6643cfa528cbf7\", srcLocModule = \"Database.PostgreSQL.Consumers.Components\", srcLocFile = \"src/Database/PostgreSQL/Consumers/Components.hs\", srcLocStartLine = 387, srcLocStartCol = 17, srcLocEndLine = 387, srcLocEndCol = 31})]}",

Though technically, in its current state, it says it will reenqueue tasks even if there are no tasks (and the error will pop every so often, but that's ok: it's pretty bad to have a query that fails even when there are no actual jobs to run), so I suspect we need two different handle.

[Raveline]

Latest commit also guarantees it doesn't fail when a single job fails to parse (without blocking the others). However, the update logic doesn't seem to work yet for some reason :(

[Raveline]

Build errors are unrelated (but I suspect we're missing some lib install in the CI). This works, and is tested. Now, the main issue is having all these rollbacks / commit in the middle of the consumer loop - it's not great. Another solution would be to have a savepoint, but I think it actually makes sense to rollback in this context. @arybczak any opinion or better solutions ?