net: coap: add support for CoAP over reliable transports

[mpenate-ellenbytech]

Add implementation of RFC 8323 (CoAP over TCP). This includes:

• TCP-specific packet parsing and creation functions
• BERT (Block-wise Extension for Reliable Transport) support
• CSM signaling code (7.01) and options
• New Kconfig options for reliable transport configuration

[sonarqubecloud]

Quality Gate passed

Issues
10 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
5.9% Duplication on New Code

See analysis details on SonarQube Cloud

[mpenate-ellenbytech]

Initial concerns for this PR. This list contains general questions and design concerns for such a large addition. For some of these I talk in length about the current implementation and how it could be improved given what I know at the end of all this development but haven't had the time to implement.

• Should this be two PR's? One that adds the reliable CoAP packet handling functionality to coap.h/c and another one that adds reliable CoAP support to CoAP client?
• I don't have a websockets testing setup for this currently so I hadn't looked at that part of the RFC.
• There is a lot of duplicated code between the two protocols:
  • CoAP client was copied and modified as a starting point for a functional implementation. I believe that the required code for reliable CoAP should be wrapped in conditional #if defined... inside the existing CoAP client. Blockwise handling is a tad different and which functions to call based on the connection type are the differences. (Also byte streaming but I detail that further below)
  • The packet assembly and parsing for TCP based packets in coap.c is a little bit of a gray area that I am unsure how to handle. The packet header varies only slightly but the key differences are no message types and the entire packet length is specified for stream parsing. When making a packet, coap_packet_tcp_update_len has some edge cases of being unable to shrink the packet currently and also needs to be called as a final part of packet construction which I think updating the length header fields should be handled in coap.c
• I didn't write support for automatically sending out CSMs, the application should call coap_client_tcp_csm_req immediately after establishing a TCP stream.
• I didn't write support for receiving CSMs, if the server wants to specify a lower Max-Message-Size Capability Option the client should respect that new size.
• The TCP CoAP client's packet reception is... not ideal. In fact the entire concept of TCP segmentation is only vaguely handled. TCP segmentation is parsed after polling ie. a socket receive blocking operation after using a function specifically meant to result in not needing a blocking operation. Currently after the poll identifies that there are bytes to be received from the TCP stream the client calls receive_tcp with max_len and after bounds verifying the initial byte(s) header for length it spin loops receiving into the coap client's buffer, parses the packet and calls the user callback with the block data. In my opinion the implementation should be switched to a non-blocking immediate receive for the entire buffer size and check the header to see if all the bytes across segmentation were received, if not it should return -EAGAIN and mark some kind of book-keeping on the current number of received bytes.
• There are three variables affecting efficient block transfer size, the buffer size provided to CoAP client, the TCP segmentation size, and the TCP CoAP CSM signal packet with a Max-Message-Size Capability Option. A CoAP BERT block can be no larger than the Max-Message-Size Capability Option negotiated by the client and server. This value will always be less than or equal to the CoAP client's buffer size. TCP segmentation size effects firmware sleep performance in many ways and particularly effects CoAP client when segmentation size is less than the client's buffer size (because of segmentation polling as noted above). Choosing these limits defined at compile time and how they're respected/limited needs a second look-over in the TCP CoAP client implementation. I believe documentation should be updated to include something discussing this point as well.