Fixes Voxel Server "stop sending" issue

In debugging with @PhilipRosedale last night, we found that when his client connects/reconnects from the domain, there was a large flood of bad "agents" connecting from his IP address. This flood of new agents was putting a great deal of stress on the _nodeHashMutex in NodeList. The locking of the _nodeHashMutex caused the voxel server to not successfully attain a pointer to the node when attempting to call nodeWithUUID().

When this case happened, the voxel server would give up after 10 attempts to get the node from the UUID and would eventually drop the node from it's sending threads. But since the domain server never saw the agent disconnect, it didn't send a new "nodeAdded()" callback to the server, and as a result the client would sit in this zombie state.

Its not clear why Philips machine seems to cause this flood of bad agents... which is still happening. But this PR will fix the zombie behavior in the voxel/particle servers.

The fix basically involved getting rid of the concept of mapping from UUIDs to nodes. We get rid of this concept by just keeping track of the SharedNodePointer instead of the UUID. By getting rid of this mapping, we no longer become dependent on locking the node list, and we're able to run without concern for deadlock.

=======
* switches the octree server "sending thread" strategy from keeping a node UUID to instead keeping a SharedNodePointer
    * this allows us to no longer query the NodeList for the nodeWithUUID()
    * which means we no-longer need to constantly get a lock on the _nodeHashMutex
    * which removes the potential deadlock in node shutdown
    * which allows us to remove the "missing node" logic - which was causing these zombie client connections
* also fixes a bug in octree-element populations that occurred when voxel server was restarted