Fix unfinished step in parallel flow

[doontagi]

related issue #3939

Motivation

• On Different behavior when interrupting a job, depending on the parallel flow order #3939, when two flows are executed in parallel, I found that even though one flow throw an interruption and terminated the job, the next step of the other flow was executed.
• And this abnormal behavior occurs only when the other flow was added first to the job
• Problem is that even if the job containing both flows were terminated and went into STOPPED status, the other flow couldn't recognize the interruption because interruption had been checked by STOPPING status.
  https://github.com/spring-projects/spring-batch/blob/9a2b1bbc96f338017aaa5df51214896f5a32d1e5/spring-batch-core/src/main/java/org/springframework/batch/core/repository/support/SimpleJobRepository.java#L290C16-L290C17
  Because the job already had been terminated and in STOPPED status, a step in the other flow cannot recognize it and proceeded as like there had been no interruption.
• The reason why this behavior didn't occur when the interruptedFlow added firstly to the job is that secondly added flow was always executed first in SplitState. So, if the two step flow would be added secondly, first step in this flow will be processed before the interrupted flow made the job status STOPPED, so it can recognize the interruption.
• If there are remaining tasks (steps) but the job was terminated due to an exception as like now, there is also a problem that the status of the job may be changed by the remaining tasks.

Modification

• Changed to wait for all asynchronous tasks to finish before throwing an exception.
• Changed a job to handle exceptions after waiting for tasks currently being processed to complete. Prevent the job from terminating �even though there are remaining tasks.

Result

• Job, Flow and Steps work same when an exception does not occur.
• Regardless of the order in which flows are added to the Job for parallel processing, if an interruption occurs, only the currently executing step is processed. That is, no further steps are executed after that.
• Close Different behavior when interrupting a job, depending on the parallel flow order #3939

[doontagi]

As before, the first caught exception would be thrown.

[doontagi]

Finished with BatchStatus.STOPPED without executing nonExecutableStep.
This test would fail with executing nonExecutableStep if it runs on the current main branch.

[doontagi]

Gentle ping to @fmbenhassine. Could you review this PR? I've fixed #3939.
Thanks!

[fmbenhassine]

Thank you for your PR!

Changed to wait for all asynchronous tasks to finish before throwing an exception.

Isn't that not desired when one of the tasks is interrupted? Meaning if one wants to interrupt a step, the idea is not to wait for other steps to finish.

The change in this PR fixes the reported issue, I just want to make sure there is no side effect on the behaviour of step interruption.