Best practices refactor: Minimize "naked" FDs (Native_handle); prefer Own_native_handle. #157

Right off the bat: This does not reference any known bug, nor would it change any API contracts; the generated code would be close to identical as well.

util::Native_handle is internally used as, while we remain POSIX-only at least, almost as nice equivalent to int (used as FD a/k/a Native_handle). That it is its own type, with certain niceties, is good. However, it does not have auto-closing (::close() in dtor and on overwrite via assignment); nor should it. It is what it is, and that thing is a real thing.

util::Own_native_handle is coming soon (in the mega-PR for #143, main [not only] PR for release 3); it is essentially unique_resource<Native_handle>; it ::close()s FD in dtor and on being overwritten (a-la unique_ptr with ::close()=deleter but sans heap use).

In the massive code review preceding release 3, we found quite a few instances of FD-leaking behaviors (~all along error paths but nevertheless). These bugs have been fixed. In many cases (not all) I did this by internally using Own_native_handle.

However: These bugs would not have existed in the first place, if all internal code followed this rule:

• Always use Own_native_handle...

• ...except when some API (that cannot be changed, such as a user-facing API, or a native call) requires a naked FD; then use Native_handle or (eventually) Native_handle::handle_t (i.e., int in POSIX).

• There is essentially no perf cost; a few = -1 ops would be added, at worst.

• The code would be cleaner in those areas; in many cases, though it would require some tactical effort, it would also be shorter. (No more "if exiting here, don't forget to un-leak some FD" type stuff.)

Priority: Eh, you know. I'd say do it at first opportunity when dealing with FDs. No need to rock the boat until then; it's not some dire problem (anymore -- those bugs are fixed -- but we don't want to add such problems again from here on either).