TCP support

[JosefWN]

Look into providing support for TCP as specified in RFC 8323.

[JosefWN]

A first step could be to refactor CoapINetwork in order to generalize the interface, and then make the DTLS examples extend CoapNetworkUDP, where CoapNetworkUDP manages the RawDatagramSocket. This would also reduce some duplicate code.

We could also implement a CoapNetworkTCP just to exercise the new CoapINetwork interface, but leaving this case out of CoapINetwork.fromUri until we have full support.

[JKRhb]

Do you think this issue is already resolved with #113? Or do we need some additional logic for correctly handling TCP? I noticed that RFC 8974 introduced a new concept called signaling codes (which we already support via #114), does the client need to take those into account somehow? I haven't had the opportunity to dive into the RFC so far.

[JosefWN]

I haven't dug into this yet, but I would guess that we need to strip away whatever TCP is already handling under the hood (deduplication, maybe retries). Even though the wire formats are similar they are not identical either, I think MessageID for example is not necessary with TCP because you have a sequence number in the network protocol to handle deduplication.

[JKRhb]

After the merge of the latest PRs, I am currently experimenting with an implementation of CoAP over TCP and WebSockets, and made some progress. I'll try to open a PR soon with some initial results, but it might take a week or two until then. As you already mentioned, the similarities and differences between the message formats require some (heavy) refactoring and at least one additional stack implementation. However, I think we are getting close :)