dpif-linux: Use poll() internally in dpif_linux_recv().

Using poll() internally in dpif_linux_recv(), instead of relying
on the results of the main loop poll() call, brings netperf CRR
performance back within 1% of par versus the code base before the
poll_fd_woke() optimizations were introduced.  It also increases
the ovs-benchmark results by about 5% versus that baseline, too.

My theory is that this is because the main loop takes long enough
that a significant number of packets can arrive during the main
loop itself, so this reduces the time before OVS gets to those
packets.

lib/netlink-socket.c

@@ -854,6 +854,19 @@ nl_sock_wait(const struct nl_sock *sock, short int events)
     poll_fd_wait(sock->fd, events);
 }
 
+/* Returns the underlying fd for 'sock', for use in "poll()"-like operations
+ * that can't use nl_sock_wait().
+ *
+ * It's a little tricky to use the returned fd correctly, because nl_sock does
+ * "copy on write" to allow a single nl_sock to be used for notifications,
+ * transactions, and dumps.  If 'sock' is used only for notifications and
+ * transactions (and never for dump) then the usage is safe. */
+int
+nl_sock_fd(const struct nl_sock *sock)
+{
+    return sock->fd;
+}
+
 /* Returns the PID associated with this socket. */
 uint32_t
 nl_sock_pid(const struct nl_sock *sock)