Update workflow diagrams (#4682)

* Update workflow pattern diagrams

Signed-off-by: Marc Duiker <marcduiker@users.noreply.github.com>

* Update workflow diagrams to new style

Signed-off-by: Marc Duiker <marcduiker@users.noreply.github.com>

* Update diagrams

Signed-off-by: Marc Duiker <marcduiker@users.noreply.github.com>

* Update workflow k8s diagram

Signed-off-by: Marc Duiker <marcduiker@users.noreply.github.com>

---------

Signed-off-by: Marc Duiker <marcduiker@users.noreply.github.com>
Co-authored-by: Mark Fussell <markfussell@gmail.com>

Author: marcduiker

daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-architecture.md

@@ -31,7 +31,7 @@ When a workflow application starts up, it uses a workflow authoring SDK to send
 
 The workflow app executes the appropriate workflow code and then sends a gRPC request back to the sidecar with the execution results.
 
-<img src="/images/workflow-overview/workflow-engine-protocol.png" alt="Dapr Workflow Engine Protocol" />
+<img src="/images/workflow-overview/workflow-engine-protocol.png" width=500 alt="Dapr Workflow Engine Protocol" />
 
 All interactions happen over a single gRPC channel and are initiated by the application, which means the application doesn't need to open any inbound ports. The details of these interactions are internally handled by the language-specific Dapr Workflow authoring SDK.
 
@@ -91,7 +91,7 @@ Workflow actor state remains in the state store even after a workflow has comple
 
 The following diagram illustrates the typical lifecycle of a workflow actor.
 
-<img src="/images/workflow-overview/workflow-actor-flowchart.png" alt="Dapr Workflow Actor Flowchart"/>
+<img src="/images/workflow-overview/workflow-actor-flowchart.png" width=600 alt="Dapr Workflow Actor Flowchart"/>
 
 To summarize:
 
@@ -113,7 +113,7 @@ Each activity actor stores a single key into the state store:
 
 The following diagram illustrates the typical lifecycle of an activity actor.
 
-<img src="/images/workflow-overview/workflow-activity-actor-flowchart.png" alt="Workflow Activity Actor Flowchart"/>
+<img src="/images/workflow-overview/workflow-activity-actor-flowchart.png" width=600 alt="Workflow Activity Actor Flowchart"/>
 
 Activity actors are short-lived:
 

daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md

@@ -710,7 +710,7 @@ The monitor pattern is recurring process that typically:
 
 The following diagram provides a rough illustration of this pattern.
 
-<img src="/images/workflow-overview/workflow-monitor-pattern.png" width=600 alt="Diagram showing how the monitor pattern works"/>
+<img src="/images/workflow-overview/workflow-monitor-pattern.png" width=800 alt="Diagram showing how the monitor pattern works"/>
 
 Depending on the business needs, there may be a single monitor or there may be multiple monitors, one for each business entity (for example, a stock). Furthermore, the amount of time to sleep may need to change, depending on the circumstances. These requirements make using cron-based scheduling systems impractical.
 
@@ -953,7 +953,7 @@ Here's an example workflow for a purchase order involving a human:
 
 The following diagram illustrates this flow.
 
-<img src="/images/workflow-overview/workflow-human-interaction-pattern.png" width=600 alt="Diagram showing how the external system interaction pattern works with a human involved"/>
+<img src="/images/workflow-overview/workflow-human-interaction-pattern.png" width=800 alt="Diagram showing how the external system interaction pattern works with a human involved"/>
 
 The following example code shows how this pattern can be implemented using Dapr Workflow.