With lwIP we have a chunked UDP payload, so just providing the
stack-internal buffer is not possible. To be able to iterate over such
a chunked payload, this change allows the `sock_*_recv_buf()` functions
to use the internal buffer context as an iteration state.
As the internal buffer space can be released when the function would
return 0, `sock_recv_buf_free()` becomes unnecessary.
This change amends the `sock` API by a set of functions to `sock` that
allow provisioning of stack-internal buffers to the caller on receive.
This allows to cover two use-cases
1. Zero-copy systems: if the stacks supported the buffer space provided
by these functions can be the same that was filled in the link-layer
2. asynchronous receive within a wrapping sock layer (e.g. `sock_dtls`
wrapping `sock_udp`): to receive packets of the lower level protocol
asynchronously, the wrapping implementation layer would currently
need to allocate its own buffer space, introducing a third buffer
space in addition to the one of the application and the network
stack. For a wrapping layer this is undesirable.
While there are security considerations exposing stack internal memory
space to the caller, I believe they are minor, as in the end the
application developer is the person in control of the node.
This introduces a new alternative and better API to `conn`. It differs in the
following aspects:
* a common address type for both IPv4 and IPv6 addresses is introduced
* communication end-points are abstracted as end-point types `sock_x_ep_t`,
containing the address, its family, its port (if required for protocol) and
the interface identifier.
* All functions require some kind of state. Sending of datagrams to the same
source or replying to incoming datagrams is thus simplified
* TCP connection establishment was overall reworked: connected sockets and
listening sockets are now two distinct types. An accept on a listening socket
than yields a connected socket
