When a repeated Scheduler job finishes a batch, it shifts to aborted state before effectively repeating.

Steps to reproduce:
- Create a Scheduler job that has repeats, and starts now,
- Run the Scheduler,
- Observe as job finishes a batch, aborts indicating its startup time is in the past, then restart for the next batch.

This situation is triggered by the startup time which is calculated at the first batch, and is re-considered when checking for the new batch. START_ASAP jobs get configured as START_AT when they are evaluated. When a batch finishes, jobs go through state COMPLETE so that they re-evaluate before being repeated, and the re-evaluation doesn't consider the original startup configuration.

The same situation occurs with real START_AT jobs, but those by design need to really start at the time they are planned, not at another time.

Thus in order to avoid regressions, this issue should probably not be fixed by considering START_AT/START_ASAP original startup configurations, but by checking if a repeat is remaining when finding a job that was configured to start too far in the past.