nanocoap_sock: add nanocoap_sock_block_request()

[benpicco]

Contribution description

This implements a nanocoap_sock_block_request() function for block-wise (block1) requests.
The function is expected to be called in a loop and will transmit a block each time it's called.

As an alternative to #17544 I simple added a iolist_t *snips to coap_pkt_t so we don't have to copy the payload into a temporary buffer and can leverage sock_udp_sendv() instead.

Testing procedure

The tests/nanocoap_cli has been extended with a (crude) put command.
It will simply upload the lyrics of the Free Software Song via blockwise PUT, it can be used with

put coap://[fe80::90a7:a6ff:fe4b:2e32%5]/song.txt

with

aiocoap-fileserver --write .

on the other end.
This will be changed to instead integrate with nanocoap_vfs to upload files and integrate with the url put/post command, but I wanted to get some feedback on the API first.

Issues/PRs references

[maribu]

Code looks good to me.

I think that the semantics of coap_get_total_len are unclear when snips in a pkt are used. With the current documentation, I would assume that it would also take any payload snips into account, but the implementation doesn't. (In fact, the code here relies on the fact that it doesn't take the snips size into account.)

It is not directly related, but I am also a bit unhappy with the documentation of coap_pkt_t::payload. As I understand it, it really points to the end of the header (included the 0xff end of options marker, if present). So even when there is no payload at all, it must still not be NULL.

I also would like the documentation to have an opinion on whether (pkt->payload_len > 0) && (pkt->snips != NULL) is valid or not. And if it is valid, how the payload when assembled back into a single continuous buffer would look like. (E.g. would pkt->payload be put in front of pkt->snips, or the other way round.)

[benpicco]

I added some documentation to coap_pkt_t. I also don't like it's API, but changing it turned out to be a larger undertaking than I had anticipated, so I turned to this less invasive approach.

coap_get_total_len() is only used by nanocoap_sock, I wonder if we should just make that an internal function.

[maribu]

ACK. Code looks good and I trust your testing. Please squash the documentation nitpicks right in.