pkg/tinydtls/sock_dtls: use ztimer_usec

[fjmolinas]

Contribution description

In #17564 tinydtls code was migrated to ztimer, but for some reason, sock_dtls was looked over, and not caught by the CI, it's now resurfaced with #17670, so this PR cleans this up.

Since sock timeous are in us this PR us using `ztimer_usec, only 32bits are required here.

I also uncrustified in a separate commit.

Testing procedure

I ran examples/dtls-sock between two native nodes, also change the timeouts from SOCK_NO_TIMEOUT to 5 * US_PER_SEC and saw it timeout after 5 second when only one native node was up:

• timeout

main(): This is RIOT! (Version: 2022.04-devel-416-g092ca-pr_tinydtls_ztimer_cleanup)
DTLS sock example application
All up, running the shell now
> dtlsc fe80::4cb2:45ff:fe3a:8461 "secure data"
dtlsc fe80::4cb2:45ff:fe3a:8461 "secure data"
Error creating session: -110
>

• success

main(): This is RIOT! (Version: 2022.04-devel-416-g092ca-pr_tinydtls_ztimer_cleanup)
DTLS sock example application
All up, running the shell now
> dtlss start
dtlss start
> ifconfig
ifconfig
Iface  5  HWaddr: 4E:B2:45:3A:84:61
          L2-PDU:1500  MTU:1500  HL:64  Source address length: 6
          Link type: wired
          inet6 addr: fe80::4cb2:45ff:fe3a:8461  scope: link  VAL
          inet6 group: ff02::1
          inet6 group: ff02::1:ff3a:8461

> New client connected
Received 11 bytes -- (echo)

main(): This is RIOT! (Version: 2022.04-devel-416-g092ca-pr_tinydtls_ztimer_cleanup)
DTLS sock example application
All up, running the shell now
> dtlsc fe80::4cb2:45ff:fe3a:8461 "secure data"
dtlsc fe80::4cb2:45ff:fe3a:8461 "secure data"
From [fe80::4cb2:45ff:fe3a:8461%5]:20220
Client got hint: hint
Connection to server successful
Sent DTLS message
Received 11 bytes: "secure data"
Terminating

Issues/PRs references

Cleanup from #17564
Needed for #17670

[kfessel]

just checked is USEC is necessary for the timeout - sadly yes to keep the sock interface "happy"

the parameter needs it since our current sock interface uses usec timeout everywhere (connect, accept, recv, send ...)

checked if usec is needed in the sock interface - unlikely

unlikely: even though linux uses struct timeval and there for provides such a high resolution

• FreeRTOS uses ms,
• WINSOCK uses ms and
• IBM is very specific in its zOS docs "While the timeval structure can be specified using mircosecond granularity, the internal TCP/IP timers used to implement this function have a granularity of approximately 100 milliseconds."

may be this could go with a similar solution to IBM for now, accept high granularity (usecs) but use an internal resolution of ms -> this PR could go for ZTIMER_MSEC and divide the values from the interface by a 1000

[fjmolinas]

may be this could go with a similar solution to IBM for now, accept high granularity (usecs) but use an internal resolution of ms -> this PR could go for ZTIMER_MSEC and divide the values from the interface by a 1000

I feel this would be out of scope of this PR, this is would an API change for sock...

[fjmolinas]

may be this could go with a similar solution to IBM for now, accept high granularity (usecs) but use an internal resolution of ms -> this PR could go for ZTIMER_MSEC and divide the values from the interface by a 1000

I feel this would be out of scope of this PR, this is would an API change for sock...

But otherwise I would agree on this, similar to what your are proposing in #16598

[fjmolinas]

All green!

[fjmolinas]

Thanks!