netlink-socket: Make dumping and doing transactions on same nl_sock safe.

netlink-socket: Make dumping and doing transactions on same nl_sock safe.

It's not safe to use a single Netlink fd to do multiple operations in an
synchronous way.  Some of the limitations are fundamental; for example, the
kernel only supports a single "dump" operation at a time.  Others are
limitations imposed by the OVS coding style; for example, our Netlink
library is not callback based, so nothing can be done about incoming
messages that can't be handled immediately.  Regardless, in OVS multicast
groups, transactions, and dumps cannot coexist on a single nl_sock.

This is only mildly irritating at the moment, but it will become much worse
later on, when dpif-linux shifts to using Netlink dumps for listing various
kinds of datapath entities.  When that happens, a dump will be in progress
in situations where the dpif-linux client might want to do other
operations.  For example, it is reasonable for the client to list flows
and, in the middle, look up information on vports mentioned in those flows.
It might be possible to simply ban and avoid such nested operations--I have
not even audited the source tree to find out whether we do anything like
that already--but that seems like an unnecessary cramp on our coding style.
Furthermore, it's difficult to explain and justify without understanding
the implementation.

This patch takes another approach, by improving the Netlink socket library
to avoid artificial constraints.  When an operation, or a dump, or joining
a multicast group would cause a problem, this patch makes the library
transparently create a separate Netlink socket.  This solves the problem
without putting any onerous restrictions on use.

This commit also slightly simplifies netdev_vport_reset_names().  It had
been written to destroy the dump object before the Netlink socket that it
used, but this is no longer necessary and doing it in the opposite order
saved a few lines of code.

Reviewed by Ethan Jackson <ethan@nicira.com>.