Refactor Job manager routes

[ryuwd]

• Renamed from job_manager to jobs
• Split into multiple modules
• Removed some endpoints in favour of expressing the desired operation(s) as single or bulk job status changes
• Used TaskGroup or ForgivingTaskGroup over asyncio.gather, etc where appropriate
• Major refactor of reschedule_job to respect the job state machine
• Additionally try to reduce the number of statements/queries generated in bulk operations

For #22
Needs DIRACGrid/DIRAC#7794

TODO:

• Tests passing
• Check rescheduling and resetJob
• fix bug in job state machine when rescheduling in JobDB
• make rescheduling and reset job tests a bit more rigorous to check I did not break anything
• regenerate client methods with autorest
• use config object to pull out MaxRescheduling from the CS instead of making a property in JobDB

[ryuwd]

65da423 is the start of using bulk insert/update statements in the job manager, and are supposed to be significantly faster than lots of single insert/update statements. I started with rescheduling and job status updates.

[ryuwd]

I should check which rows were successfully updated in the previous operation and exclude unsuccessful updates from the JDL update statement.

[ryuwd]

@fstagni do you have any view on things to watch out for with bulk inserts and updates, based on previous experience in DIRAC? I can foresee some risks of things becoming inconsistent, which could be mitigated by reducing the batch sizes or carefully checking the input and results of each statement execution.