Support for DTLS and other transport layers, make client async

[osobiehl]

features:

• Client now uses async and tokio UDP sockets as a default
• Observe now takes ownership of the client to avoid missed packets
• DTLS is supported using webrtc-rs
• DTLS is a feature, can be turned off if needed
• Other backends for transport can be provided by users. They must be able to provide a SockAddr for use with observe, but this could be theoretically hardcoded if you want to use some non-ip protocol
• Server is reworked to support multiple listeners at the same time
• Server should no longer block on a single long async request handlers
• Added tests for DTLS using PSK and PKI
• Added example for DTLS using PSK
• Moved all tests to use tokio::test

Still not sure about:

• handler API takes a Box<CoapRequest>> and returns a Box<CoapRequest>. I did this to avoid copies and still allow for closures as handlers. The ergonomics are not great though
• handlers for server must be Send + Sync since they can run concurrently
• naming convention e.g., DTLSConfig vs DtlsConfig

[coveralls]

coverage: 74.962% (+1.7%) from 73.312%
when pulling d2db6ae on osobiehl:feature/jb/add-dtls-support
into 773aacf on Covertness:master.

[Covertness]

It's a long-awaited improvement of this repo. Thank you for your tremendous help.

[osobiehl]

hmm, it looks like requests may occasionally fail (udp makes no guarantees for reaching the target, so this is expected). Maybe it would make sense to do retries in the future. I would do that in a separate PR after this is merged though

[Covertness]

hmm, it looks like requests may occasionally fail (udp makes no guarantees for reaching the target, so this is expected). Maybe it would make sense to do retries in the future. I would do that in a separate PR after this is merged though

Yeah. Retries would reduce the probability of errors.

[osobiehl]

OK, this looks good to go from my side. Please consider reviewing.
I am also debating rewriting the entire backend to use tower. That way, it is easy to add built-in support for retries/rate limiting. This should not be a breaking change for the future.

Since the changes in this PR are massively breaking, it might also make sense to do some cleanup before doing a major release (e.g., allow options on lowest level of requests)

[Covertness]

Good job. I have two questions in the reviewing. Please have a look.

[osobiehl]

Good job. I have two questions in the reviewing. Please have a look.

are the comments published? I see no comments

[Covertness]

some suggestions

[Covertness]

Good job. I have two questions in the reviewing. Please have a look.

are the comments published? I see no comments

sorry. forgot to submit

[osobiehl]

ok, changes are implemented. I have also prepared a PR where I add retries to the client over UDP / DTLS if a confirmable message is sent, as well as some basic handling for non-piggybacked responses. I will open it once this is merged, so maybe it would make sense to wait a little before a next release?