Potential handle leaks in dup_worker

[Ken Brown]

I've had occasion to work through dtable::dup_worker, and I'm seeing the 
potential for leaks of path_conv handles.  I haven't seen any evidence that the 
leaks actually occur, but the code should probably be cleaned up if I'm right.

dup_worker calls clone to create newfh from oldfh.  clone calls copyto, which 
calls operator=, which calls path_conv::operator=, which duplicates the 
path_conv handle from oldfh to newfh.  Then copyto calls reset, which calls 
path_conv::operator<<, which again duplicates the path_conv handle from oldfh to 
newfh without first closing the previous one.  That's the first leak.

Further on, dup_worker calls newfh->pc.reset_conv_handle (), which sets the 
path_conv handle of newfh to NULL without closing the existing handle.  So 
that's a second leak.  This one is easily fixed by calling close_conv_handle 
instead of reset_conv_handle.

As a practical matter, I think the path_conv handle of oldfh is always NULL when 
dup_worker is called, so there's no actual leak.

I may well be confused and/or missing something.

Ken