Fix DHCP/OS metadata flow setup locking issues from issue #6.
The DHCP and OS meta flow setup functions were locking in the wrong order. They would try to grab the cn_node_t lock associated with the dhcp server cn_node_t and the osmeta server cn_node_t first, then do some flow setup work that would result in the csw lock associated with both of those nodes being taken. The order is always csw, cport, cnode. So now these functions follow that convention, and things are happy. This would typically manifest when a new node was entering from the metadata server (always from the pending list, as I saw it), and conflicting with a packet in msg (i.e., an ARP involving the DHCP server or the OS metadata server).
Showing with 18 additions and 2 deletions