Replace all instances "the the" with "the"

Author: AlexLanzano

wolfHSM/src/chapter07.md

@@ -231,7 +231,7 @@ typedef int (*whServerCustomCb)(
 
 Custom server callback functions are associated with unique identifiers (IDs), which correspond to indices into the server's custom callback dispatch table. The client will refer to the callback by it's ID when it requests invocation.
 
-The custom callback has access to data passed from the client by value or by reference (useful in a shared memory system) through the `whMessageCustomCb_Request` argument passed into the callback function. The callback can act on the input data and produce output data that can be passed back to the client through th e`whMessageCustomCb_Response` argument. The custom callback does not need to handle sending or receiving any of the input / output client data, as this is handled externally by wolfHSM. The response structure also contains fields for an error code and return code to propagate back to the client. The error code should be populated by the callback, and the return code will be set the the return value from the custom callback.
+The custom callback has access to data passed from the client by value or by reference (useful in a shared memory system) through the `whMessageCustomCb_Request` argument passed into the callback function. The callback can act on the input data and produce output data that can be passed back to the client through th e`whMessageCustomCb_Response` argument. The custom callback does not need to handle sending or receiving any of the input / output client data, as this is handled externally by wolfHSM. The response structure also contains fields for an error code and return code to propagate back to the client. The error code should be populated by the callback, and the return code will be set the return value from the custom callback.
 
 ### Client Side
 

wolfMQTT/src/chapter03.md

@@ -40,7 +40,7 @@ The Sensor Network client implements the MQTT-SN protocol for low-bandwidth netw
 
 A special feature of MQTT-SN is the ability to use QoS level -1 (negative one) to publish to a predefined topic without first connecting to the gateway. There is no feedback in the application if there was an error, so confirmation of the test would involve running the `sn-client` first and watching for the publish from the `sn-client_qos-1`. There is an example provided in `/examples/sn-client/sn-client_qos-1`. It requires some configuration changes of the gateway.
 
-* Enable the the QoS-1 feature, predefined topics, and change the gateway name in `gateway.conf`:
+* Enable the QoS-1 feature, predefined topics, and change the gateway name in `gateway.conf`:
 
 ```
 QoS-1=YES

wolfSSL-JNI/src/chapter08.md

@@ -119,7 +119,7 @@ A random amount of time is injected into each client thread before:
   2) Doing I/O operations after the handshake
 
 The maximum amount of sleep time for each of those is "maxSleep", or 3 seconds
-by default. This is intended to add some randomness into the the client thread
+by default. This is intended to add some randomness into the client thread
 operations.
 
 Example usage:

wolfSSL/src/chapter02.md

@@ -281,7 +281,7 @@ Example `Makefile.common` changes for Raspberry Pi with Cortex-A53:
 #### Building with configure with cross-compile
 
 The configure script in the main project directory can perform a cross-compile
-build with the the gcc-arm-none-eabi tools. Assuming the tools are installed in
+build with the gcc-arm-none-eabi tools. Assuming the tools are installed in
 your executable path:
 
 ```sh