Fixes to timeout of sendMessageVector and refactor of sendBuffer for …

…consistency (#224)

* Fixes to timeout of sendMessageVector and refactor of sendBuffer for consistency.

* Update size table.

* Fixing some small MISRA related issues

* Formatting fix

* Minor fixes for CBMC.

* Updated logical flow to break instead.

* Revert "Updated logical flow to break instead."

This reverts commit 0ac1c6a.

* Updated unit tests for coverage.

* Fix MQTT_Publish Proof

* Fix proofs for connect/sub/unsub API functions

* New timing scheme.

* Update config defaults to reflect new timing change.

* Fix doxygen. Fix formatting. Fix memory table.

* Doxygen fixes.

* Fix CBMC proofs

* Added License identifier back.

* Swapped from warning to error for Visual Studio.

Co-authored-by: Jason Carroll <czjaso@amazon.com>
Co-authored-by: Soren Ptak <skptak@amazon.com>
Co-authored-by: Aniruddha Kanhere <60444055+AniruddhaKanhere@users.noreply.github.com>

docs/doxygen/pages.dox

@@ -114,7 +114,7 @@ which is defined by @ref MQTT_MAX_CONNACK_RECEIVE_RETRY_COUNT.
 For @ref mqtt_processloop_function and @ref mqtt_receiveloop_function, the timeout value represents the <i>minimum</i> duration that will be spent in the function, provided there are no network errors.
 Should the timeout be set to 0, then the loop will run for a single iteration. A single iteration of a loop consists of an attempt to receive a single byte from the network, and
 if the single byte receive was successful, then attempt(s) to receive the rest of the packet (with retry attempts governed by @ref MQTT_RECV_POLLING_TIMEOUT_MS), followed by sending acknowledgement response, if needed
-(with retry attempts governed by @ref MQTT_SEND_RETRY_TIMEOUT_MS), and then, finally deserialization of the packet received and a call to the application callback.
+(with retry attempts governed by @ref MQTT_SEND_TIMEOUT_MS), and then, finally deserialization of the packet received and a call to the application callback.
 If the first read did not succeed, then instead the library checks if a ping request needs to be sent (only for the process loop).
 
 See the below diagrams for a representation of the above flows:
@@ -154,8 +154,8 @@ Some configuration settings are C pre-processor constants, and some are function
 @section MQTT_RECV_POLLING_TIMEOUT_MS
 @copydoc MQTT_RECV_POLLING_TIMEOUT_MS
 
-@section MQTT_SEND_RETRY_TIMEOUT_MS
-@copydoc MQTT_SEND_RETRY_TIMEOUT_MS
+@section MQTT_SEND_TIMEOUT_MS
+@copydoc MQTT_SEND_TIMEOUT_MS
 
 @section MQTT_MAX_CONNACK_RECEIVE_RETRY_COUNT
 @copydoc MQTT_MAX_CONNACK_RECEIVE_RETRY_COUNT

docs/doxygen/timeouts.dox

@@ -9,7 +9,7 @@ The timeouts and the recommended configurations are listed below.
 2. [MQTT Keep Alive interval](@ref mqtt_timeouts_keep_alive)
 3. [MQTT Ping Response timeout](@ref mqtt_timeouts_ping_response)
 4. [MQTT Receive Polling timeout](@ref mqtt_timeouts_receive_polling)
-5. [MQTT Send Retry timeout](@ref mqtt_timeouts_send_retry)
+5. [MQTT Send timeout](@ref mqtt_timeouts_send)
 6. [Timeouts for MQTT_ProcessLoop and MQTT_ReceiveLoop APIs](@ref mqtt_timeouts_process_receive_loop)
 7. [Timeout for MQTT_Connect](@ref mqtt_timeouts_connect)
 
@@ -67,10 +67,8 @@ without any data received, we recommend using a value larger than the Transport
 
 The MQTT Receive Polling timeout can be set by defining the configuration @ref MQTT_RECV_POLLING_TIMEOUT_MS.
 
-@section mqtt_timeouts_send_retry MQTT Send Retry timeout
-MQTT Send Retry timeout is the maximum duration between non-empty network transmissions while sending an MQTT packet via the
-@ref mqtt_processloop_function or @ref mqtt_receiveloop_function API functions. This timeout represents the maximum duration
-that is allowed for no data transmission over the network through the Transport Send function.
+@section mqtt_timeouts_send MQTT Send timeout
+MQTT Send timeout is the maximum duration allowed to send an MQTT packet over the transport interface.
 
 It is important to note that having this timeout too short will result in MQTT being disconnected due to the possibility
 of partial data being sent. If you have small TCP buffers and a high latency network, the optimum value for the timeout
@@ -80,7 +78,7 @@ hitting a timeout of Transport Send before any data could be sent to transport l
 than the Transport Send timeout. If a dummy implementation of the @ref MQTTGetCurrentTimeFunc_t timer function,
 that always returns 0, is used, then this timeout must be set to 0.
 
-The MQTT Send Retry timeout can be set by defining the configuration @ref MQTT_SEND_RETRY_TIMEOUT_MS.
+The MQTT Send timeout can be set by defining the configuration @ref MQTT_SEND_TIMEOUT_MS.
 
 @section mqtt_timeouts_process_receive_loop Timeouts for MQTT_ProcessLoop and MQTT_ReceiveLoop APIs
 This timeout is passed as an argument to @ref mqtt_processloop_function or @ref mqtt_receiveloop_function API functions.