Actively notfiy a job of an abort request

[medihack]

With PR #1081, we added a feature to mark a currently running job for abortion, but we have to poll the database in the task ourselves to determine whether this mark was set (represented by the aborting status). As discussed in #511, it would be nice if the task was actively notified of an abortion (without the need for intense database polling) using a PostgreSQL listen-notify. We could then raise an asyncio.CancelledError in an async task. It's unclear what to do with a sync task (maybe a callback method like context.listen_abort(cb: Callable?!). It should be optional and triggered by something like job_manager.cancel_job_by_id(33, abort=True, notify=True).
It would be best implemented after the worker refactoring #933, as it must be integrated into the worker class.

[ewjoachim]

It would be best implemented after the worker refactoring #933

Or be part of the design of #933

[ewjoachim]

If we do #1083, is this worth the complexity ? I won't close this but I think it's interesting to spell out the gains we expect from this before tackling it.

[medihack]

In some cases, it could simplify the abortion process and save the user some code (e.g., no need for another asyncio task that monitors the abort status). On the other hand, it's not a feature that needs to have high priority or be integrated right now as part of the worker refactoring (the refactoring is complicated enough anyway). It's more a nice to have feature and something I have not seen in any other distributed task queue library. So I would say, let us leave this issue open and see what the future brings. Regarding #1083, it's the next thing I'll deal with.