This will work around the current debian package build failure

Related T1498

Works around https://github.com/ClearcodeHQ/pytest-postgresql/issues/16

instead of replicating the same logging code everywhere.

This reverts commit f267f454.

Pushed by mistake.

see https://github.com/pytest-dev/pytest/issues/4641
It should be possible to let this constraint go when celery 4.3 is out

also remove now useless celery_testing.py and scheduler_testing.py files.

this uses the pytest-postgresql package to manage the database life cycle.

the result backend must be configured to be able to save (celery) group
results (as it is now the case for lister tasks for example).

that allows to respawn any task immediately (or any later date).

so this method can be used to respawn a task immediately.

and not only pending tasks.

to display also the status and priority fields.

Not all keys are mandatory, so do not expect all the possible keys for the
task_type table to be given when calling create_task_type().

Note: no validation is made whether the given set of keys fullfill the table
constraints.

instead of float numbers.

and add some kind of unit tests.

in favor of the 'swh-scheduler api-server' command.

also log an eventual exception instead of crashing the runner service.

use functions instead of methods.

This is required to be able to use celery pytest fixtures so one can
really test celery tasks (especially when a task spawns sub tasks).

one (get_queue_lenth) of the 3 methods has been added as (monkeypatched)
method on the Celery class for the sake of bw compat, but this should really
be removed as well as soon as possible (seems only used in swh-archiver).

so that logging level config can be consistently set for all swh-scheduler
commands.

since it's actually the responsibility of each subcommand to decide whether it
can run without a properly configured scheduler instance.

This is also required so the user can run:

  swh-scheduler subcommand --help

even with a non-properly configured scheduler.

These commands do what they say, ie. start a runner, listener or API server
process.

Note that processes are not daemonized and run in front.

Typically used as:

  swh-scheduler --cls local --database postgresql:///?service=swh api-server --host 127.0.0.1 --port 5008

  swh-scheduler --cls remote --url http://127.0.0.1:5008 runner --period 10

  swh-scheduler --cls remote --url http://127.0.0.1:5008 listener

This is needed to be able to add more context objects (see following revisions).

It is meant to be used to declare swh tasks via the task decorator
instead of subclassing the (now deprecated) Task class.

It is typically used like:

  from swh.scheduler.celery_backend.config import app
  from swh.scheduler.tasks import SWHTask

  @app.task(base=SWHTask)
  def ping():
      return 'pong'

class-based router is a remainder of celery 3.

- do use a dedicated logger instead of the root logger,
- add a couple of logging statements (in perform_action methods),
- replace the --verbose cli option by --log-level

- allow to pass the loglevel as a string,
- kill useless tmp variables,
- add a filter to prevent amqp's heartbeat_tick debug messages.

This lets go of the metaclass madness imported from Celery 3, and goes for an
explicit task registration mechanism as advised in Celery 4.

We do explicit registration of all our tasks in the 'worker ready' signal, just
before they automatically subscribe to the task queues.

Unfortunately that signal is not emitted by the "test fixture" worker, so we
need to explicitly register class-based tasks that are being used in tests. This
doesn't show up for functions as the @task decorator handles registration.

since the task-type is mandatory, make it a command argument instead of
an option, and make it variadic, so one can list several pending task
types at once.

Also do not use the pager. Let the user decide whether she wants paginated
results.

that allows to easily insert a new task in the scheduler's database, eg.

  swh-scheduler --database 'service=swh-scheduler' \
        task add swh-lister-debian distribution=stretch policy=oneshot

so that we can expose it to cli tools.

that lists available task types.

That only works for actual workers (the celeryd_after_setup signal isn't sent by
the test fixture), so keep the workaround in the fixture