Reloading a scheduler job while it's running or in error unschedules it

A scheduler job is reloaded when the classloader its job class comes from is reset (e.g. an extension is installed, upgraded or uninstalled, see XWIKI-14494 and XWIKI-24332) and, since XWIKI-15952, when the definition of the job (cron expression, script, job class, etc.) is modified.

SchedulerPlugin#reloadJob() deletes the job from Quartz, which also deletes its triggers, adds it back, and then only schedules it again when the job was in the PAUSED or NORMAL Quartz state. In any other state the job is left without any trigger: it's not scheduled anymore and never runs again, while the job page still displays the Normal status. The only way to get it running again is to unschedule and schedule it again manually.

This happens in particular when the job is reloaded while it's:

• running (BLOCKED state), for a job class annotated with @DisallowConcurrentExecution, e.g. a Java job coming from an extension. For example a long-running job whose definition is modified while it executes.
• in error (ERROR state), which Quartz sets when the job class cannot be instantiated, e.g. because the extension providing it is missing or broken. Reinstalling or fixing the extension resets the classloader and reloads the job, which is exactly when it should start running again; instead it loses its schedule.

In addition, the currentState != null check of reloadJob(), meant to do nothing for a job unknown to the scheduler, is never false once the scheduler is started: Quartz returns the NONE state for an unknown job, not null. So reloading a job unknown to Quartz still builds it, which saves the job page when its context user, language or wiki is empty, and adds a job without trigger to Quartz.

Steps to reproduce

1. Schedule a job whose job class is annotated with @DisallowConcurrentExecution and whose execution takes some time
2. Trigger it and, while it's running, modify its cron expression and save the job page (before XWIKI-15952: install, upgrade or uninstall a JAR extension on the namespace the job class comes from instead)
3. Once the execution is finished, look at the Scheduler home page: the job is still displayed as Normal but has no next fire time and never runs again

Both the BLOCKED and ERROR cases, as well as the reload of an unknown job, were verified with unit tests based on a started in-memory Quartz scheduler.