nanocoap_sock: implement observe (Client-Side)

[benpicco]

Contribution description

Testing procedure

A new observe command was added to tests/net/nanocoap_cli:

> observe coap://[fe80::d07c:7cff:fe6d:9441]/time
2025-01-23 16:25:24,793 # 00000000  32  37  36  32  30  0A
2025-01-23 16:25:25,175 # 00000000  32  38  30  30  32  0A
2025-01-23 16:25:26,174 # 00000000  32  39  30  30  31  0A
2025-01-23 16:25:27,175 # 00000000  33  30  30  30  31  0A
2025-01-23 16:25:28,175 # 00000000  33  31  30  30  32  0A
2025-01-23 16:25:29,173 # 00000000  33  32  30  30  31  0A
2025-01-23 16:25:30,173 # 00000000  33  33  30  30  31  0A
2025-01-23 16:25:31,175 # 00000000  33  34  30  30  31  0A
2025-01-23 16:25:32,175 # 00000000  33  35  30  30  32  0A
2025-01-23 16:25:33,175 # 00000000  33  36  30  30  32  0A
2025-01-23 16:25:34,173 # 00000000  33  37  30  30  31  0A
2025-01-23 16:25:35,173 # 00000000  33  38  30  30  31  0A

> observe coap://[fe80::d07c:7cff:fe6d:9441]/time off
2025-01-23 16:25:36,148 # gnrc_sock: timeout != 0 within the asynchronous callback lead to unexpected delays within the asynchronous handler.
2025-01-23 16:25:36,148 # 00000000  33  38  39  37  36  0A
> 

Issues/PRs references

based on #21147

[maribu]

Looks quite good to me :)

I have been thinking for ages whether we should go for async sockets for nanocoap (both client and server), and provide the synchronous sock API on top of that.

IMO the synchronous interface is optimized for the rather synthetic "shell app use case". Any "headless" MCU would more likely want to use an async API and the ability to run server and client on the same endpoint.

But that is orthogonal to this PR.

[riot-ci]

Murdock results

❌ FAILED

99a66d5 examples/nanocoap_server: add output if registration fails

Success	Failures	Total	Runtime
1102	1	9371	01m:48s

Build failures (1)

Application	Target	Toolchain	Runtime (s)	Worker
tests/net/nanocoap_cli	hifive1b	gnu	3.46	mobi3

Artifacts

[maribu]

lgtm, some more comments inline and the CI also has comments.