Contribution description

How often have you been looking for a bug, and it felt like chasing a ghost because memory was messed up?
How often was it a buffer you have unsuspectingly increased in size, which was not static?
(The right answer is: Yes 😄)
That's why non-static uint8_t buffer[CONFIG_INCREASE_ON_DEMAND] is likely a footgun.

Most importantly, this PR makes that a response buffer for nanocoap_link_format_get() has to be user allocated.
I could have just made it static, but this would bring up a concurrency issue.

Secondly, a buffer [CONFIG_NANOCOAP_BLOCK_HEADER_MAX] is added to nanocoap_sock_t.
This was before allocated in various nanocoap functions. I moved it to the socket because this is likely allocated in a user thread. Therefore the stack size of that user's thread is no longer our problem 😅. And not so unlikely, the user allocates the socket with static.

Testing procedure

Start a CoAP fileserver: aiocoap-fileserver --bind [::] .
Flash a sam54-xpro and connect it via ethernet to the coap fileserver:
USEMODULE+=nanocoap_vfs CFLAGS+=-DCONFIG_NANOCOAP_QS_MAX=1024 BOARD=same54-xpro make -C examples/networking/gnrc/gnrc_networking flash term PORT=/dev/ttyACM0

On master: ncget coap://[fe80::be63:bb80:6473:faa9]/ crashes on my setup.
On this banch it succeeds and prints the directory content.

Issues/PRs references