Sockets are overly difficult to close when a network stack reset happens

The `network_socket_close()` API returns immediately with `-EAGAIN` if the network stack is currently resetting. This means that one needs to call the API in a loop to ensure that sockets are properly closed after a reset. [See example](https://github.com/CHERIoT-Platform/network-stack/blob/588106a83e05b70ebc9a845c5d6aec4fc303a4b4/examples/05.HTTP_SERVER/http_server.cc#L188). We shouldn't ask users to write such an ugly loop.

@davidchisnall suggests to have the loop inside of the `network_socket_close()` API.

There have also been discussions in the past (among others with @nwf) about finding a good way to have all threads exit the compartment in the case of a reset. This is [related to this issue](https://github.com/CHERIoT-Platform/network-stack/issues/31). I didn't give up on this and Wes had concrete ideas for the switcher. Unfortunately, this would make it hard to have this loop inside of the TCP/IP compartment.

The loop could, however, be implemented as a simple wrapper.

One could perhaps also picture exposing a futex that tells when the reboot is done to avoid the dirty loop altogether.

Start at the network_socket_close() API and the usage in examples/05.HTTP_SERVER/http_server.cc around line 188. Review issue #31 and the reset-related discussion to understand the compartment and thread-exit constraints. Done means callers no longer need an explicit retry loop after a network stack reset, with the chosen wrapper or signaling behavior documented by the relevant tests.

Written by the indexing model from the issue text.