* Remove default parameters in doc journal
Making sure the examples are explicit about them
* Don't rely on default parameters in docs
As those default parameters might not be present for all implementations
* remove unrelated changes from PR
* Update BehaviorTestKitSpec.scala
* deduplicate logic for IODispatcher #24604
* introduce a resolveDispatcher helper in ActorAttributes
* mention akka.stream.materializer.blocking-io-dispatcher instead of akka.stream.blocking-io-dispatcher in scaladocs
* fix a flaky test
* cosmetic changes in the touched files
* move resolveDispather helper to the Dispatcher companion object under a new name resolve
* filter out mima warning
* fix mima excludes after the 2.5.11 release
* address review comments
* update stream-io.md with the correct dispatcher config key
* mark ActorAttributes.Dispatcher#resolve as internal API
* use the dispatche config key in ActorMaterializer
* add private[akka] to the resolve methods
progressed with cleanup, removing the same thread exec context is
weird... causes issues :-/ Need to debug more, could be that some race
also exists in mapAsync then :\
WIP
finish ask impl via watch stage
mima
consistency spec
fix paradox, and fix adding ask/watch to javadsl source
follow up review
For the current Chunker if the upstream sends larger messages than the
chunk size the buffer can slowly fill up until the app OOMs. Change it
so it only pulls if the buffer is empty
+str #24229 remove protobuf changes, which do not need to be made in this PR
docs
moved things
config object
subscription timeout confifmed working, also, attributes
document attributes for sub timeout
tests for the source also failing when it should
additional demand test
implemented protection from materializing "in cycles"; would be nice in
types but that breaks the niceness of use of the types
SinkRef/SourceRef...
cleanup
no idle timeout built in, can use the Timeout stages
more docs
simplest change to prevent exposing SinkRef => SourceRef => SinkRef cycle
Things to decide:
* is it ok to require using `getSource` / `getSink` as Java API, is there better naming?
* where should the constructors go? I'd say just in regular javadsl/scaladsl `Source`/ `Sink` objects
move constructors to {javadsl,scaladsl}.{Source,Sink} companion objects
Remove now useless "canMaterialize" field
Separate stage (implementation) from ref (wrapped actor ref) to make it clearer what is serialized
Clarify that partner refs are not optional in on-the-wire interfaces
minor cleanup in SourceRefStage
Renamed the stages but questionable if that really helps ;)
cleanups, better docs
cleanup, fix docs compilation
fix mima
got rid of Futures in the materialized values of stream refs
