Refactor Handlers for None-correctness

[FrNecas]

Follow up of the discussion with @lbarcziova in #1579 (comment)

Currently, handlers are instantiated in 2 times, once in Steve and then in the celery task corresponding to the handler. However, the use-cases for these two initializations are different:

• Steve just uses pre_check() and perhaps some other stuff but doesn't run it
• celery task runs the handler

This causes problems with regards to None correctness as explained in the comment linked above. Ideally, a task that can be retried should not have its CeleryTask argument set to None (without the task attached, retrying is not possible and does not make sense). However, the initialization inside Steve does not have a celery task yet to attach, hence it must be set to None (a bit of a chicken-egg problem).

A solution that I assume could work (however, feel free to come up with anything else):

• split each handler (including the abstract classes) into 2 parts (naming is just a suggestion):
  • BaseHandler - implements just the pre_check and similar stuff
  • RunnableHandler - also implements run and inherits from BaseHandler
• inside Steve initialize just the BaseHandler which does not need a CeleryTask even for a retriable job handler.
• inside tasks, initialize RunnableHandler which in the case of retriable handlers will have non-Optional CeleryTask argument

This is a blocker for #1433 (the implementation from #1579 would not pass mypy's strict checks -- however it does not make sense to block it on this rather large refactoring)

[FrNecas]

Follow-up from arch:

Another option to handle this situation is to not instantiate a handler in Steve. This would mean that pre_check and check_if_actor_can_run_job_and_report would have to be made static/class methods and everything required would have to be passed to them. From briefly looking at this, the methods access all kinds of stuff from the instance attributes (job/package config, helper instance -- this would have to be instantiated, which requires ogr Project, trigger and a lot of other stuff) so this approach may not really be feasible, the code of these methods may get quite messy, if we wanted to pass everything there.