5.2.1 - Ensure only 1 job is claimed for PostgreSQL

What's Changed

• fix: Ensure only 1 job is claimed for PostgreSQL by @paxuclus in #40

Full Changelog: 5.2.0...5.2.1

5.2.0 - Add Job Status Service

What's Changed

• feat: add job status service by @HenrikVogel in #38
• fix: doctrine transaction and unified timeout setting by @HenrikVogel in #39

Full Changelog: 5.1.1...5.2.0

5.1.1 - Fix PostgreSQL stale job reset

Merge pull request #37 from netlogix/fix/postgres-reset-stale

5.1.0 - Add signal for failed jobs

Merge pull request #36 from netlogix/feat/fail-signal

5.0.0 - Introduce PostgreSQL support

Adds native PostgreSQL support and refactors the scheduler into
database-specific implementations with dedicated SQL dialects
and migrations.

The job running state is now treated as a multi-state value in PHP,
aligning the code with the existing database representation.

4.0.0 - Use React/Loop and React/Process for job execution

Switches to netlogix/jobqueue-pool to:

• execute jobs async,
• keep the DBAL connection alive while waiting, and
• update the job database row to keep track of "activity".

This makes use of React/Loop and React/Process.

Updating the "activity" every couple of seconds allows determining whether a given job is currently stalled.

3.3.2 - Retry "retryables" up to 5 times when scheduling

Scheduling new jobs sometimes fails due to database deadlocks. These are "retryable", so the system will simply try again.

3.3.1 - Duplicate Job Execution in Multi-Worker Setups

Jobs can now be scheduled to run again only after the previous execution has fully completed.

In a multi-worker setup, the previous implementation could allow a new worker to start the same job while it was still running on another worker. This behavior was typically undesired and could lead to race conditions or duplicate processing.

With this fix, a new instance of the job is only started once the current instance is no longer marked as running.

3.3.0 - Improve resilience against deadlocks during job claiming

Claiming unclaimed jobs already attempts to make optimal use of available indexes.
However, deadlock exceptions can still occur and cause the worker process to fail,
even though these exceptions implement Doctrine's RetryableException interface.

This change introduces a retry mechanism that performs up to 5 additional attempts
with exponentially increasing wait intervals between each try.

Ensure poll loop breaks periodically even with active jobs

To allow for regular garbage collection, the poll loop must break
every few minutes.

Previously, this only happened when the job queue was completely empty
and no new job was returned from a next() call. This approach fails when
the queue consistently contains jobs and its processing time exceeds
the configured working window—preventing any break from occurring.

This change moves the break condition to after each job execution,
ensuring regular exit points regardless of queue state.