feat(tasks): add dummy job executor

[anpicci]

• add DummyJobExecutorMonitorTask, a periodic task (every 10 seconds) that picks up every job in Received state, moves it to Waiting, and schedules a one-shot executor task for it
• add DummyJobExecutorTask, a one-shot task that simulates the execution of a single job by walking it through the state machine's valid path Waiting → Matched → Running → Done via set_job_statuses, holding a per-job MutexLock while it runs
• register and publicly export both tasks as jobs:DummyJobExecutorMonitorTask and jobs:DummyJobExecutorTask
• add unit tests covering serialisation, scheduling, locking, and the status transitions, plus manual usage documentation

Motivation

This provides a standalone "dummy" job execution pipeline for exercising the DiracX task framework end-to-end — job discovery, status transitions, task fan-out, and per-job locking — without requiring execution through legacy DIRAC. It is intended for demo deployments.

Closes #964.

Implementation notes

• The executor walks the full Matched → Running → Done chain in a single set_job_statuses call with increasing timestamps, since the state machine silently rejects a direct jump to Done.
• All database dependencies (JobDB, JobLoggingDB, TaskQueueDB, JobParametersDB) and Config are injected through the task framework's dependency-injection machinery, matching the contract of set_job_statuses in diracx-logic.
• Deliberately out of scope: JDL handling, real matching/pilots, and any Gubbins/local development changes.

Validation

• full diracx-tasks test suite passes (73 tests), including 8 tests for the two new tasks
• all pre-commit hooks pass on the changed files (ruff check/format, mypy, mdformat, codespell)

[read-the-docs-community]

Documentation build overview

📚 diracx | 🛠️ Build #33632811 | 📁 Comparing c556409 against latest (74a1a6a)

  🔍 Preview build  

1 file changed

± admin/how-to/tasks/run-task-manually/index.html