Express the need of a non-blocking TransportRecv_t (#318)

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:
----------
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->
- [ ] 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.

---------

Co-authored-by: Paul Höhn <paulh@MacBook-Air-von-Paul.local>
Co-authored-by: DakshitBabbar <100972343+DakshitBabbar@users.noreply.github.com>
Co-authored-by: GitHub Action <action@github.com>
Co-authored-by: DakshitBabbar <dakshitbabbar.iitd@gmail.com>

docs/doxygen/porting.dox

@@ -55,6 +55,8 @@ struct NetworkContext {
 };
 @endcode
 
+Please note that it is HIGHLY RECOMMENDED that the transport receive implementation does NOT block.
+
 @section mqtt_porting_time Time Function
 @brief The MQTT library relies on a function to generate millisecond timestamps, for the
 purpose of calculating durations and timeouts, as well as maintaining the keep-alive mechanism