docs: Fix spelling errors across various pages on the site (#18533)

This commit fixes numerous spelling errors across the site and also
removes unnecessary whitespace that was present in the edited files.

website/content/commands/intention/list.mdx

@@ -2,7 +2,7 @@
 layout: commands
 page_title: 'Commands: Intention List'
 description: >-
-  The `consul intention list` command returns all L4 service intentions, including a unique ID and intention precendence. It was deprecated in Consul v1.9.0; use `consul config` instead.
+  The `consul intention list` command returns all L4 service intentions, including a unique ID and intention precedence. It was deprecated in Consul v1.9.0; use `consul config` instead.
 ---
 
 # Consul Intention List

website/content/commands/kv/index.mdx

@@ -2,7 +2,7 @@
 layout: commands
 page_title: 'Commands: KV'
 description: >-
-  The `consul kv` command interacts with Consul's key/value store. It exposes top level commands to insert, update, read, and delte data from the store.
+  The `consul kv` command interacts with Consul's key/value store. It exposes top level commands to insert, update, read, and delete data from the store.
 ---
 
 # Consul KV

website/content/commands/services/deregister.mdx

@@ -2,7 +2,7 @@
 layout: commands
 page_title: 'Commands: Services Deregister'
 description: |
-  The `consul services deregister` command removes a service from the Consul catalog. Run the commeand on the agent that initially registered the service.
+  The `consul services deregister` command removes a service from the Consul catalog. Run the command on the agent that initially registered the service.
 ---
 
 # Consul Agent Service Deregistration
@@ -13,12 +13,12 @@ Corresponding HTTP API Endpoint: [\[PUT\] /v1/agent/service/deregister/:service_
 
 The `services deregister` command deregisters a service with the local agent.
 Note that this command can only deregister services that were registered
-with the agent specified and is intended to be paired with `services register`. 
-By default, the command deregisters services on the local agent. 
+with the agent specified and is intended to be paired with `services register`.
+By default, the command deregisters services on the local agent.
 
 We recommend deregistering services registered with a configuration file by deleting the file and [reloading](/consul/commands/reload) Consul. Refer to [Services Overview](/consul/docs/services/services) for additional information about services.
 
-The following table shows the [ACLs](/consul/api-docs/api-structure#authentication) required to run the `consul services deregister` command: 
+The following table shows the [ACLs](/consul/api-docs/api-structure#authentication) required to run the `consul services deregister` command:
 
 | ACL Required    |
 | --------------- |

website/content/commands/services/register.mdx

@@ -14,7 +14,7 @@ Corresponding HTTP API Endpoint: [\[PUT\] /v1/agent/service/register](/consul/ap
 The `services register` command registers a service with the local agent.
 This command returns after registration and must be paired with explicit
 service deregistration. This command simplifies service registration from
-scripts. Refer to [Register Services and Health Checks](/consul/docs/services/usage/register-services-checks) for information about other service registeration methods. 
+scripts. Refer to [Register Services and Health Checks](/consul/docs/services/usage/register-services-checks) for information about other service registration methods.
 
 The following table shows the [ACLs](/consul/api-docs/api-structure#authentication) required to use the `consul services register` command:
 

website/content/docs/agent/limits/usage/limit-request-rates-from-ips.mdx

@@ -4,9 +4,9 @@ page_title: Limit traffic rates for a source IP address
 description: Learn how to set read and request rate limits on RPC and gRPC traffic from all source IP addresses to a Consul resource.
 ---
 
-# Limit traffic rates from source IP addresses 
+# Limit traffic rates from source IP addresses
 
-This topic describes how to configure RPC and gRPC traffic rate limits for source IP addresses. This enables you to specify a budget for read and write requests to prevent any single source IP from overwhelming the Consul server and negatively affecting the network. For information about setting global traffic rate limits, refer to [Set a global limit on traffic rates](/consul/docs/agent/limits/usage/set-global-traffic-rate-limits). For an overview of Consul's server rate limiting capabilities, refer to [Limit traffic rates overview](/consul/docs/agent/limits). 
+This topic describes how to configure RPC and gRPC traffic rate limits for source IP addresses. This enables you to specify a budget for read and write requests to prevent any single source IP from overwhelming the Consul server and negatively affecting the network. For information about setting global traffic rate limits, refer to [Set a global limit on traffic rates](/consul/docs/agent/limits/usage/set-global-traffic-rate-limits). For an overview of Consul's server rate limiting capabilities, refer to [Limit traffic rates overview](/consul/docs/agent/limits).
 
 <EnterpriseAlert>
 
@@ -28,7 +28,7 @@ You should also monitor read and write rate activity and make any necessary adju
 
 ## Define rate limits
 
-Create a control plane request limit configuration entry in the `default` partition. The configuration entry applies to all client requests targeting any partition. Refer to the [control plane request limit configuration entry](/consul/docs/connect/config-entries/control-plane-request-limit) reference documentation for details about the available configuration parameters. 
+Create a control plane request limit configuration entry in the `default` partition. The configuration entry applies to all client requests targeting any partition. Refer to the [control plane request limit configuration entry](/consul/docs/connect/config-entries/control-plane-request-limit) reference documentation for details about the available configuration parameters.
 
 Specify the following parameters:
 
@@ -37,11 +37,11 @@ Specify the following parameters:
 -  `read_rate`: Specify overall number of read operations per second allowed from the service.
 -  `write_rate`: Specify overall number of write operations per second allowed from the service.
 
-You can also configure limits on calls to the key-value store, ACL system, and Consul catalog. 
+You can also configure limits on calls to the key-value store, ACL system, and Consul catalog.
 
-## Apply the configuration entry 
+## Apply the configuration entry
 
-If your network is deployed to virtual machines, use the `consul config write` command and specify the control plane request limit configuration entry to apply the configuration. For Kubernetes-orchestrated networks, use the `kubectl apply` command. 
+If your network is deployed to virtual machines, use the `consul config write` command and specify the control plane request limit configuration entry to apply the configuration. For Kubernetes-orchestrated networks, use the `kubectl apply` command.
 
 <Tabs>
 <Tab heading="HCL" group="hcl">
@@ -69,4 +69,4 @@ $ kubectl apply control-plane-request-limit.yaml
 
 ## Disable request rate limits
 
-Set the [limits.request_limits.mode](/consul/docs/agent/config/config-files#mode-1) in the agent configuration to `disabled` to allow services to exceed the specified read and write requests limits. The `disabled` mode applies to all request rate limits, even limits specifed in the [control plane request limits configuration entry](/consul/docs/connect/config-entries/control-plane-request-limit).  Note that any other mode specified in the agent configuration only applies to global traffic rate limits.  
+Set the [limits.request_limits.mode](/consul/docs/agent/config/config-files#mode-1) in the agent configuration to `disabled` to allow services to exceed the specified read and write requests limits. The `disabled` mode applies to all request rate limits, even limits specified in the [control plane request limits configuration entry](/consul/docs/connect/config-entries/control-plane-request-limit).  Note that any other mode specified in the agent configuration only applies to global traffic rate limits.

website/content/docs/agent/limits/usage/set-global-traffic-rate-limits.mdx

@@ -6,22 +6,22 @@ description: Use global rate limits to prevent excessive rates of requests to Co
 
 # Set a global limit on traffic rates
 
-This topic describes how to configure rate limits for RPC and gRPC traffic to the Consul server. 
+This topic describes how to configure rate limits for RPC and gRPC traffic to the Consul server.
 
-## Introduction 
+## Introduction
 
 Rate limits apply to each Consul server separately and limit the number of read requests or write requests to the server on the RPC and internal gRPC endpoints.
 
 Because all requests coming to a Consul server eventually perform an RPC or an internal gRPC request, global rate limits apply to Consul's user interfaces, such as the HTTP API interface, the CLI, and the external gRPC endpoint for services in the service mesh.
 
-Refer to [Initialize Rate Limit Settings](/consul/docs/agent/limits/init-rate-limits) for additional information about right-sizing your gRPC request configurations. 
+Refer to [Initialize Rate Limit Settings](/consul/docs/agent/limits/init-rate-limits) for additional information about right-sizing your gRPC request configurations.
 
-## Set a global rate limit for a Consul server   
+## Set a global rate limit for a Consul server
 
 Configure the following settings in your Consul server configuration to limit the RPC and gRPC traffic rates.
 
 - Set the rate limiter [`mode`](/consul/docs/agent/config/config-files#mode-1)
-- Set the [`read_rate`](/consul/docs/agent/config/config-files#read_rate) 
+- Set the [`read_rate`](/consul/docs/agent/config/config-files#read_rate)
 - Set the [`write_rate`](/consul/docs/agent/config/config-files#write_rate)
 
 In the following example, the Consul server is configured to prevent more than `500` read and `200` write RPC calls:
@@ -53,10 +53,10 @@ limits = {
 
 </CodeTabs>
 
-## Monitor request rate traffic 
+## Monitor request rate traffic
 
-You should continue to mmonitor request traffic to ensure that request rates remain within the threshold you defined. Refer to [Monitor traffic rate limit data](/consul/docs/agent/limits/usage/monitor-rate-limits) for instructions about checking metrics and log entries, as well as troubleshooting informaiton.
+You should continue to monitor request traffic to ensure that request rates remain within the threshold you defined. Refer to [Monitor traffic rate limit data](/consul/docs/agent/limits/usage/monitor-rate-limits) for instructions about checking metrics and log entries, as well as troubleshooting information.
 
 ## Disable request rate limits
 
-Set the [`limits.request_limits.mode`](/consul/docs/agent/config/config-files#mode-1) to `disabled` to allow services to exceed the specified read and write requests limits, even limits specified in the [control plane request limits configuration entry](/consul/docs/connect/config-entries/control-plane-request-limit). Note that any other mode specified in the agent configuration only applies to global traffic rate limits. 
+Set the [`limits.request_limits.mode`](/consul/docs/agent/config/config-files#mode-1) to `disabled` to allow services to exceed the specified read and write requests limits, even limits specified in the [control plane request limits configuration entry](/consul/docs/connect/config-entries/control-plane-request-limit). Note that any other mode specified in the agent configuration only applies to global traffic rate limits.

website/content/docs/agent/wal-logstore/index.mdx

@@ -24,15 +24,15 @@ WAL implements a traditional log with rotating, append-only log files. WAL resol
 
 The existing BoltDB log store inefficiently stores append-only logs to disk because it was designed as a full key-value database. It is a single file that only ever grows. Deleting the oldest logs, which Consul does regularly when it makes new snapshots of the state, leaves free space in the file. The free space must be tracked in a `freelist` so that BoltDB can reuse it on future writes. By contrast, a simple segmented log can delete the oldest log files from disk.
 
-A burst of writes at double or triple the normal volume can suddenly cause the log file to grow to several times its steady-state size. After Consul takes the next snapshot and truncates the oldest logs, the resulting file is mostly empty space. 
+A burst of writes at double or triple the normal volume can suddenly cause the log file to grow to several times its steady-state size. After Consul takes the next snapshot and truncates the oldest logs, the resulting file is mostly empty space.
 
 To track the free space, Consul must write extra metadata to disk with every write. The metadata is proportional to the amount of free pages, so after a large burst write latencies tend to increase. In some cases, the latencies cause serious performance degradation to the cluster.
 
-To mitigate risks associated with sudden bursts of log data, Consul tries to limit lots of logs from accumulating in the LogStore. Significantly larger BoltDB files are slower to append to because the tree is deeper and freelist larger. For this reason, Consul's default options associated with snapshots, truncating logs, and keeping the log history have been aggressively set toward keeping BoltDB small rather than using disk IO optimally. 
+To mitigate risks associated with sudden bursts of log data, Consul tries to limit lots of logs from accumulating in the LogStore. Significantly larger BoltDB files are slower to append to because the tree is deeper and freelist larger. For this reason, Consul's default options associated with snapshots, truncating logs, and keeping the log history have been aggressively set toward keeping BoltDB small rather than using disk IO optimally.
 
-But the larger the file, the more likely it is to have a large freelist or suddenly form one after a burst of writes. For this reason, the many of Consul's default options asssociated with snapshots, truncating logs, and keeping the log history aggressively keep BoltDT small rather than uisng disk IO more efficiently. 
+But the larger the file, the more likely it is to have a large freelist or suddenly form one after a burst of writes. For this reason, the many of Consul's default options associated with snapshots, truncating logs, and keeping the log history aggressively keep BoltDT small rather than using disk IO more efficiently.
 
-Other reliability issues, such as [raft replication capacity issues](/consul/docs/agent/telemetry#raft-replication-capacity-issues), are much simpler to solve without the performance concerns caused by storing more logs in BoltDB. 
+Other reliability issues, such as [raft replication capacity issues](/consul/docs/agent/telemetry#raft-replication-capacity-issues), are much simpler to solve without the performance concerns caused by storing more logs in BoltDB.
 
 ### WAL approaches storage issues differently
 
@@ -43,11 +43,11 @@ When directly measured, WAL is more performant than BoltDB because it solves a s
 The WAL backend has been tested thoroughly during development:
 
 - Every component in the WAL, such as [metadata management](https://github.com/hashicorp/raft-wal/blob/main/types/meta.go), [log file encoding](https://github.com/hashicorp/raft-wal/blob/main/types/segment.go) to actual [file-system interaction](https://github.com/hashicorp/raft-wal/blob/main/types/vfs.go) are abstracted so unit tests can simulate difficult-to-reproduce disk failures.
- 
+
 - We used the [application-level intelligent crash explorer (ALICE)](https://github.com/hashicorp/raft-wal/blob/main/alice/README.md) to exhaustively simulate thousands of possible crash failure scenarios. WAL correctly recovered from all scenarios.
 
 - We ran hundreds of tests in a performance testing cluster with checksum verification enabled and did not detect data loss or corruption. We will continue testing before making WAL the default backend.
 
 We are aware of how complex and critical disk-persistence is for your data.
 
-We hope that many users at different scales will try WAL in their environments after upgrading to 1.15 or later and report success or failure so that we can confidently replace BoltDB as the default for new clusters in a future release.
+We hope that many users at different scales will try WAL in their environments after upgrading to 1.15 or later and report success or failure so that we can confidently replace BoltDB as the default for new clusters in a future release.

website/content/docs/agent/wal-logstore/revert-to-boltdb.mdx

@@ -5,7 +5,7 @@ description: >-
   Learn how to revert Consul to the BoltDB backend after enabled the WAL (write-ahead log) LogStore backend shipped in Consul 1.15.
 ---
 
-# Revert storage backend to BoltDB from WAL 
+# Revert storage backend to BoltDB from WAL
 
 This topic describes how to revert your Consul storage backend from the experimental WAL LogStore backend to the default BoltDB.
 
@@ -18,14 +18,14 @@ The overall process for reverting to BoltDB consists of the following steps. Rep
 
 ## Stop target server gracefully
 
-Stop the target server gracefully. For example, if you are using `systemd`, 
+Stop the target server gracefully. For example, if you are using `systemd`,
 run the following command:
 
 ```shell-session
 $ systemctl stop consul
 ```
 
-If your environment uses configuration management automation that might interfere with this process, such as Chef or Puppet, you must disable them until you have completely revereted the storage backend.
+If your environment uses configuration management automation that might interfere with this process, such as Chef or Puppet, you must disable them until you have completely reverted the storage backend.
 
 ## Remove data directory from target server
 
@@ -73,4 +73,4 @@ If necessary, clean up any `raft.wal.bak` directories. Replace `/data-dir` with
 
 ```shell-session
 $ rm /data-dir/raft.bak
-```
+```