doc: Diagrams for intro and interaction examples (#27907)

akka-docs/src/main/paradox/typed/actors.md

@@ -59,6 +59,8 @@ Java
 With these in place we can define our first Actor, and it will say
 hello!
 
+![hello-world1.png](./images/hello-world1.png)
+
 Scala
 :  @@snip [IntroSpec.scala](/akka-actor-typed-tests/src/test/scala/docs/akka/typed/IntroSpec.scala) { #hello-world-actor }
 
@@ -106,6 +108,8 @@ Let's make a `HelloWorldBot` that receives the reply from the `Greeter` and send
 of additional greeting messages and collect the replies until a given max number
 of messages have been reached.
 
+![hello-world2.png](./images/hello-world2.png)
+
 Scala
 :  @@snip [IntroSpec.scala](/akka-actor-typed-tests/src/test/scala/docs/akka/typed/IntroSpec.scala) { #hello-world-bot }
 
@@ -173,6 +177,8 @@ The next example is more realistic and demonstrates some important patterns:
 * Handling state by changing behavior
 * Using multiple actors to represent different parts of a protocol in a type safe way
 
+![chat-room.png](./images/chat-room.png)
+
 ### Functional Style
 
 First we will show this example in a functional style, and then the same example is shown with an

akka-docs/src/main/paradox/typed/interaction-patterns.md

@@ -26,6 +26,10 @@ The fundamental way to interact with an actor is through @scala["tell", which is
 
 Tell is asynchronous which means that the method returns right away, when the statement after it is executed there is no guarantee that the message has been processed by the recipient yet. It also means there is no way to know if the message was received, the processing succeeded or failed.
 
+**Example:**
+
+![fire-forget.png](./images/fire-forget.png)
+
 With the given protocol and actor behavior:
 
 Scala
@@ -61,6 +65,10 @@ Many interactions between actors requires one or more response message being sen
 
 In Akka the recipient of responses has to be encoded as a field in the message itself, which the recipient can then use to send (tell) a response back.
 
+**Example:**
+
+![request-response.png](./images/request-response.png)
+
 With the following protocol:
 
 Scala
@@ -105,6 +113,10 @@ Java
 
 Most often the sending actor does not, and should not, support receiving the response messages of another actor. In such cases we need to provide an `ActorRef` of the right type and adapt the response message to a type that the sending actor can handle.
 
+**Example:**
+
+![adapted-response.png](./images/adapted-response.png)
+
 Scala
 :  @@snip [InteractionPatternsSpec.scala](/akka-actor-typed-tests/src/test/scala/docs/akka/typed/InteractionPatternsSpec.scala) { #adapted-response }
 
@@ -150,6 +162,10 @@ In an interaction where there is a 1:1 mapping between a request and a response
 
 The interaction has two steps, first we need to construct the outgoing message, to do that we need an @scala[`ActorRef[Response]`]@java[`ActorRef<Response>`] to put as recipient in the outgoing message. The second step is to transform the successful `Response` or failure into a message that is part of the protocol of the sending actor.
 
+**Example:**
+
+![ask-from-actor.png](./images/ask-from-actor.png)
+
 Scala
 :  @@snip [InteractionPatternsSpec.scala](/akka-actor-typed-tests/src/test/scala/docs/akka/typed/InteractionPatternsSpec.scala) { #actor-ask }
 
@@ -180,6 +196,10 @@ Some times you need to interact with actors from outside of the actor system, th
  
 To do this we use @scala[`ActorRef.ask` (or the symbolic `ActorRef.?`) implicitly provided by `akka.actor.typed.scaladsl.AskPattern`]@java[`akka.actor.typed.javadsl.AskPattern.ask`] to send a message to an actor and get a @scala[`Future[Response]`]@java[`CompletionState[Response]`] back.
 
+**Example:**
+
+![ask-from-outside.png](./images/ask-from-outside.png)
+
 Scala
 :  @@snip [InteractionPatternsSpec.scala](/akka-actor-typed-tests/src/test/scala/docs/akka/typed/InteractionPatternsSpec.scala) { #standalone-ask }
 
@@ -207,6 +227,10 @@ The child is created with the context it needs to do the work, including an `Act
 
 As the protocol of the session actor is not a public API but rather an implementation detail of the parent actor, it may not always make sense to have an explicit protocol and adapt the messages of the actors that the session actor interacts with. For this use case it is possible to express that the actor can receive any message (@scala[`Any`]@java[`Object`]).
 
+**Example:**
+
+![per-session-child.png](./images/per-session-child.png)
+
 Scala
 :  @@snip [InteractionPatternsSpec.scala](/akka-actor-typed-tests/src/test/scala/docs/akka/typed/InteractionPatternsSpec.scala) { #per-session-child }
 
@@ -234,6 +258,10 @@ end up repeating the same way of aggregating replies and want to extract that to
 There are many variations of this pattern and that is the reason this is provided as a documentation
 example rather than a built in `Behavior` in Akka. It is intended to be adjusted to your specific needs.
 
+**Example:**
+
+![aggregator.png](./images/aggregator.png)
+
 This example is an aggregator of expected number of replies.
 Requests for quotes are sent with the given `sendRequests` function to the two hotel actors, which both speak
 different protocols. When both expected replies have been collected they are aggregated with the given `aggregateReplies`
@@ -283,6 +311,10 @@ are under heavy load simultaneously. This technique is explained in depth in Jef
 There are many variations of this pattern and that is the reason this is provided as a documentation
 example rather than a built in `Behavior` in Akka. It is intended to be adjusted to your specific needs.
 
+**Example:**
+
+![tail-chopping.png](./images/tail-chopping.png)
+
 Scala
 :  @@snip [TailChopping.scala](/akka-actor-typed-tests/src/test/scala/docs/akka/typed/TailChopping.scala) { #behavior }
 
@@ -307,6 +339,10 @@ Java
 
 The following example demonstrates how to use timers to schedule messages to an actor. 
 
+**Example:**
+
+![timer.png](./images/timer.png)
+
 The `Buncher` actor buffers a burst of incoming messages and delivers them as a batch after a timeout or when the number of batched messages exceeds a maximum size.
 
 Scala
@@ -372,7 +408,11 @@ The normal pattern for expecting a reply is to include an @apidoc[akka.actor.typ
 for a sharded actor but if @scala[`ctx.self`]@java[`ctx.getSelf()`] is sent and the sharded actor is moved or passivated then the reply
 will sent to dead letters.
 
-An alternative is to send the `entityId` in the message and have the reply sent via sharding:
+An alternative is to send the `entityId` in the message and have the reply sent via sharding.
+
+**Example:**
+
+![sharded-response.png](./images/sharded-response.png)
 
 Scala
 :  @@snip [sharded.response](/akka-cluster-sharding-typed/src/test/scala/docs/akka/cluster/sharding/typed/ShardingCompileOnlySpec.scala) { #sharded-response }