Align submit(Callable) delegation in AsyncTaskExecutor

[bebeis]

Summary

AsyncTaskExecutor.submit(Callable) currently documents that, as of 6.1, its default implementation delegates to execute(Runnable).

However, the implementation still invokes the deprecated execute(Runnable, long) variant with TIMEOUT_INDEFINITE.

This change aligns the default submit(Callable) implementation with:

• its existing Javadoc,
• the default submit(Runnable) implementation, and
• the deprecation direction of execute(Runnable, long).

Historical Context

execute(Runnable, long) was deprecated earlier because common AsyncTaskExecutor implementations do not meaningfully support start timeouts. (see gh-27959)

Later, in 6.1, default implementations were introduced for both submit(Runnable) and submit(Callable), with Javadoc stating delegation to execute(Runnable). While submit(Runnable) follows that contract, submit(Callable) still routes through execute(Runnable, long).

This change brings submit(Callable) in line with that 6.1 contract and restores consistency between the two default submit(...) variants.

Regression Test

A regression test has been added to verify the default dispatch path.

For an AsyncTaskExecutor implementation that:

• inherits the default submit(Callable) implementation, and
• overrides both execute(Runnable) and execute(Runnable, long),

the test now verifies that submit(Callable) delegates to execute(Runnable) rather than execute(Runnable, long).

Impact

Within Spring Framework itself, this does not affect the built-in AsyncTaskExecutor implementations.

Executors with specialized submission behavior already override submit(Callable), and VirtualThreadTaskExecutor only implements execute(Runnable), so the effective behavior remains unchanged there.

For external AsyncTaskExecutor implementations that inherit the default submit(Callable) implementation and override execute(Runnable, long), this changes the default dispatch path from execute(Runnable, long) to execute(Runnable).

That change is intentional here, to make the default implementation consistent with its documented 6.1 behavior.