CompletionStage callbacks can prefer dispatcher over common ForkJoinPool

[leviramsey]

The Scala standard library's conversion from Scala future to Java CompletionStage defines the "non-Async" versions to effectively call the Async version with the Java common ForkJoinPool specified. This subtly conflicts with the common understanding of the difference between the non-Async version, and the Asyncversion, as evidenced by various AI answers:

Copilot

thenCompose: Uses the thread of the previous stage; no new thread pool unless explicitly provided.
thenComposeAsync: If you don’t pass an Executor, it uses the ForkJoinPool.commonPool(). If you do pass an Executor, it uses that.

Gemini

thenCompose (without "Async") aims to run the dependent task on the same thread that completed the previous CompletableFuture.
thenComposeAsync guarantees that the dependent task will run on a different thread (either the default ForkJoinPool.commonPool() Executor or a specific Executor you provide).

The parasitic behavior of the non-Async version is not desirable for the futures returned by Akka (consider that the future returned from asking a remote actor would be completed on the remoting dispatcher!), but there's not a great reason to use the common FJP in an Akka application: the default dispatcher provides an FJP which is well-suited to short CPU-bound tasks (including with better observability).

This adapts the Scala standard library's conversion to one where the executor to prefer is specified at the time of conversion. CompletionStage-returning calls where it's practical to shift onto the default dispatcher are then adapted to use this:

• asks of EntityRefs in typed cluster sharding
• coordination lease operations
• events-by-slice firehose methods which return completion stages

[JustinPihony]

nit: Just remove

[JustinPihony]

These can be combined - likely would be via sbt formatting