Major Description
When jobs, particularly (long-running) reports, are scheduled/asked to run and there are multiple Syncope core nodes available in the cluster, the current method of obtaining the job status via Spring and Quartz fails to report back the status accurately, specially when the job bean is scheduled on one node and the status check query is performed on another.
To support this scenario, job status details would be persisted in the backend database in a new table, and the job engine would be responsible to add/update/delete details in this table. Status query checks would then look into this table to report back current status instead of obtaining the status from the Spring bean responsible for execution.
it was discussed that the initial changeset would go into master and be targeted to Syncope v3, and then may be backported to 2.x pending feasibility and complication.