Revisit `taskTerminationTimeout` semantics on `SimpleAsyncTaskExecutor/Scheduler`

[jhoeller]

Following up on #35254 (comment), there is a need to clarify the semantics of taskTerminationTimeout on SimpleAsyncTaskExecutor/Scheduler - and potentially to make the time of interruption configurable, similar to waitForTasksToCompleteOnShutdown on ThreadPoolTaskExecutor/Scheduler.

However, the common scenario is not quite analogous since loosely executing individual Threads are not being stopped as part of lifecycle management: With SimpleAsyncTaskExecutor as well as SimpleAsyncTaskScheduler, the only stopping of such loose tasks happens on close(), so it seems sensible to leave some room for them to complete based on their own lifecycle management (as of 6.2.10). For scenarios where immediate interruption is nevertheless desirable, we could provide a configuration flag, effectively opting into pre-6.2.10 behavior.

[jhoeller]

As of 6.2.11, a cancelRemainingTasksOnClose flag on SimpleAsyncTaskExecutor allows for opting into immediate interruption on close (as we did before 6.2.10 in case of a taskTerminationTimeout having been set). Note that this works in combination with taskTerminationTimeout (interrupting before the timeout in this case) but also on its own (just interrupting on close without any waiting). Note that we only recommend setting cancelRemainingTasksOnClose to true if threads are commonly expected to be stuck; otherwise, it is preferable to leave room for a graceful shutdown without such immediate interruption.

This is somewhat analogous to the waitForTasksToCompleteOnShutdown flag on ThreadPoolTaskExecutor but with the difference that waitForTasksToCompleteOnShutdown is an alternative to the multi-phase shutdown within Spring's lifecycle management. Remaining tasks in a ThreadPoolTaskExecutor always have the chance to complete without immediate interruption, either within the lifecycle stop timeout or within the awaitTermination timeout on shutdown.

Also, the close() method on SimpleAsyncTaskExecutor is analogous to the JDK 19 introduced close() method on ExecutorService (see #35316) which does not interrupt worker threads at all unless the shutdown thread itself is being interrupted.

[github-actions]

Fixed via f62519b