When reading from the socket with `sock_tcp_read()` it would only return
data from at most one internal connection buffer, even if the buffer
passed to `sock_tcp_read()` is larger and there is more data available
in the connection. This patch makes `sock_tcp_read` process all the
available data so long as there's more data to read available
immediately.
lwip receives network buffers that are made available to lwip_sock_tcp
calling `netconn_recv_tcp_pbuf`. The size of these buffers depends on
the size of the network packets. An application calling `sock_tcp_read`
can pass any arbitrary buffer size to read (copy) from these internal
network buffers, which may be smaller. lwip_sock_tcp keeps around the
last network buffer (`struct pbuf last_buf`) and the offset into this
buffer already consumed by the application (`last_offset`).
However, when multiple application reads from the same `pbuf` buffer
occur, the `last_offset` must be updated incrementing it. The code had
a bug that would work only when `last_offset` was either 0 (no previous
partial read) or when the current read was consuming all the remaining
data (when `buf_len == copylen`).
This patch fixes the issue an allows multiple reads from the same
buffer.
Netifs without link status support will keep sending discover
messages with increasing time between.
Netifs that support link status will wait for the link to be up,
and then start sending.
Netifs that support link status but send no link status events
will continue to not work (unless link status is up from the
first check when setting it up).
Set link state correctly in lwIP for interfaces that support
the NETOPT_LINK option. Interfaces that do not support it
(like tap for native arch) remain up all the time.
Netdevs that support NETOPT_LINK but do not send NETDEV_EVENT_LINK_UP/DOWN
events will end up with a mismatched link state - but DHCP would
already not start for them either.
Use netifapi to signal lwIP to do the work in its own thread.
With PR #14349 the double stack mode for lwIP was activated. The ATWINC15x0 driver was provided before the changes in PR #14349 but merged after that. Therefore, the changes for the driver were not taken into account anymore and have to be applied accordingly.
IP4_ADDR_ANY is a generic address of type IPv4 when lwIP is compiled
with both IPv4 and IPv6, so we need to extract the `ip4_addr_t`
component when using with `netif_add()` as that is the expected type.
