Update style on core workflow image and light/dark theme (#4567)

* Update style on core workflow image and light/dark theme
Update style on how boundary works image and light/dark theme
Remove redundant image

* docs: Fix typo

---------

Co-authored-by: Robin Beck <stellarsquall@protonmail.ch>
Co-authored-by: Dan Heath <76443935+Dan-Heath@users.noreply.github.com>

website/content/docs/concepts/workers.mdx

@@ -18,7 +18,8 @@ such as the database, KMS, Vault, identity providers, and plugins.
 private targets. Instead of exposing a private network to the public, or allowing users to have access to entire private networks, workers create a direct network
 tunnel between users and targets.
 
-![Boundary architecture example showing workers and controllers](/img/access-model.png)
+![How Boundary Works](/img/how-boundary-works_light.png#light-theme-only)
+![How Boundary Works](/img/how-boundary-works_dark.png#dark-theme-only)
 
 ## Capabilities
 You can use workers in various ways depending on your needs, as follows:

website/content/docs/install-boundary/architecture/high-availability.mdx

@@ -22,7 +22,7 @@ The following ports should be available:
 
 The general architecture for the server infrastructure requires 3 controllers and 3 workers. Note that it is possible to run a controller and worker within the same process, but the guide here assumes separate deployments. The documentation here uses virtual machines running on Amazon EC2 as the example environment, but this use case can be extrapolated to almost any cloud platform to suit operator needs:
 
-![](/img/production.png)
+![](/img/boundary-network.png)
 
 As shown above, Boundary is broken up into its controller and worker server components across 3 [EC2 instances](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance), in
 3 separate [subnets](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/subnet), in three separate availability zones, with the controller API and UI being publically exposed by an [application load balancer (ALB)](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lb). The worker and controller VM's are in independent [auto-scaling groups](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/autoscaling_group), allowing them to maintain their exact capacity.

website/content/docs/oss/index.mdx

@@ -24,7 +24,8 @@ Boundary Community Edition is designed to be straightforward to understand, high
 and resilient. It can run in clouds, on-premise, or within secure enclaves.
 Boundary does not require an agent to be installed on the end host.
 
-![How Boundary Works](/img/how-boundary-works.png)
+![How Boundary Works](/img/how-boundary-works_light.png#light-theme-only)
+![How Boundary Works](/img/how-boundary-works_dark.png#dark-theme-only)
 
 ## Tutorial
 

website/content/docs/overview/what-is-boundary.mdx

@@ -31,7 +31,8 @@ It also gives a brief walkthrough of the end user's experience.
 
 The illustration below displays Boundary's core workflow.
 
-![Boundary core workflow](/img/boundary-core-workflow.png)
+![Boundary core workflow](/img/boundary-core-workflow_light.png#light-theme-only)
+![Boundary core workflow](/img/boundary-core-workflow_dark.png#dark-theme-only)
 
 The core Boundary workflow consists of four stages: