Express the need of a non-blocking TransportRecv_t

[jadaber]

Express the need of a non-blocking TransportRecv_t #317

Description

• changed documentation to express the need of a non-blocking TransportRecv_t
• mentioned that a non-blocking implementation is highly recommended in porting.dox and in the transportinterface
• did go more into detail in TransportRecv_t what the effects of a blocking recv implementation are

Test Steps

only changed documentation

Checklist:

• I have tested my changes. No regression in existing tests.
• I have modified and/or added unit-tests to cover the code changes in this Pull Request.

Related Issue

#317
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[DakshitBabbar]

Hey @diopoex,
Thanks for this PR, looks good to me. I've added a small suggestion, let me know your thoughts.

[DakshitBabbar]

I was wondering if it would be better to include the fact that the user can also implement their own keep alive mechanism in which case the non-blocking receive function may/may not affect the keep alive mechanism. Something like this:

/*
 * @note It is HIGHLY RECOMMENDED that the transport receive
 * implementation does NOT block.
 * coreMQTT will continue to call the transport interface if it receives
 * a partial packet until it accumulates enough data to get the complete
 * MQTT packet. 
 * A non‐blocking implementation is also essential so that the library's inbuilt 
 * keep‐alive mechanism can work properly, given the user chooses to use 
 * that over their own keep alive mechanism.
 */

Let me know what you think.

[jadaber]

Yes that's perfect I think!

[rohitmadan07]

/bot run formatting