[test] Drop call to CubicWebConfiguration.load_cwctl_plugins in unittest_cwctl.py This is no longer need now that we call load_available_configurations() in the "list" command (see 5e7282bdf140).

[web] Extract a base class out WebConfiguration This will be used to build a CubicWebPyramidConfiguration in following changeset.

[tox] Drop reference to removed init_instance.py file in flake8-ok-files.txt The file got removed in 1b9fd8bda1cd.

[web] Put 'use-uicache' option in level 2 So that users do not get prompted with this. Follow-up on c34590161082.

[server] Add a "scheduler" command to run repository scheduler This commands starts the repository scheduler as a standalone process that should complement a CubicWeb web instance running as a WSGI application. Added a log message in repository's shutdown method to help testing the command (i.e. make sure the method is called after the scheduler stopped). Related to #17057223.

[cwconfig] Do not instantiate a repo with a scheduler in repository method None of the caller of this method need the repository to have a scheduler and having a scheduler should be something that's explicitly requested.

[server] Make cubicweb/server/utils.py flake8-clean

[server] Drop utils's LoopTask and TasksManager classes not used anymore Related to 17057223.

[server] replace repository's tasks manager by a scheduler Repository() does not accept anymore a 'tasks_manager' argument but rather a 'scheduler' argument which is expected to be an instance of sched.scheduler class. The drop the _tasks_manager attribute of the repository and adjust all internal usages of it. In particular, in the 'repo_stats' service we do not export 'looping_tasks' statistics anymore as there's no way to retrieve this anymore from a web instance. Closes #17057223.

[server] introduce a scheduler class to run repository "looping tasks" We just use the sched module from the standard library and introduce a tiny Python2/3 compatibility layer (more for convenience actually). The "looping" aspect of tasks (previously in LoopTask class) is re-implemeted as a `schedule_periodic_task` function. This is a reasonably thin layer as compared to LoopTask/TasksManager classes. Only the "restart" aspect of LoopTask is no longer present as I'm not sure it's worth keeping. The advantage of using this (in addition to eventually dropping our custom code) is that this scheduler class provides a `run` method that blocks the process while running tasks in its queue. So we can rely on this to have a 'scheduler' ctl command (see forthcoming patch) that would only run "looping tasks" without having to implement the "blocking" aspect ourself. Related to #17057223.