In xenInotifyXendDomainsDirLookup() the wrong UUID variable is used
to search in the config info list.

In xenInotifyEvent() the event is dispatched if it's NULL.

Both were introduced in bc898df2.

The commit cb51aa48 "Fix up connection
reference counting." changed the driver closing and virConnectPtr
unref-logic in virConnectClose().

Before this commit virConnectClose() closed all drivers of the given
virConnectPtr and virUnrefConnect()'ed it afterwards. After this
commit the driver-closing is done in virUnrefConnect() if and only if
the ref-count of the virConnectPtr dropped to zero.

This change in execution order leads to a virConnectPtr leak, at least
for connections to Xen.

The relevant call sequences:

virConnectOpen() -> xenUnifiedOpen() ...

... xenInotifyOpen() -> virConnectRef(conn)

... xenStoreOpen() -> xenStoreAddWatch() -> conn->refs++

virConnectClose() -> xenUnifiedClose() ...

... xenInotifyClose() -> virUnrefConnect(conn)

... xenStoreClose() -> xenStoreRemoveWatch() -> virUnrefConnect(conn)

Before the commit this additional virConnectRef/virUnrefConnect calls
where no problem, because virConnectClose() closed the drivers
explicitly and the additional refs added by the Xen subdrivers were
removed properly. After the commit this additional refs result in a
virConnectPtr leak (including a leak of the hypercall file handle;
that's how I noticed this problem), because now the drivers are only
close if and only if the ref-count drops to zero, but this cannot
happen anymore, because the additional refs from the Xen subdrivers
would only be removed if the drivers get closed, but that doesn't
happen because the ref-count cannot drop to zero.

The fix for this problem is simple: remove the
virConnectRef/virUnrefConnect calls from the Xen subdrivers (see
attached patch). Maybe someone could explain why the Xen Inotify and
Xen Store driver do this extra ref-counting, but none of the other Xen
subdrivers. It seems unnecessary to me and can be removed without
problems.
Signed-off-by: NChris Lalancette <clalance@redhat.com>

* src/Makefile.am, src/proxy_internal.c, src/proxy_internal.h
  src/sexpr.c, src/sexpr.h, src/xen_unified.c, src/xen_unified.h,
  src/xen_internal.c, src/xen_internal.h, src/xen_inotify.c,
  src/xen_inotify.h, src/xend_internal.c, src/xend_internal.h,
  src/xm_internal.c, src/xm_internal.h, src/xs_internal.c,
  src/xs_internal.h: Move to src/xen/ directory
* proxy/Makefile.am, proxy/libvirt_proxy.c, src/Makefile.am,
  src/libvirt.c, tests/sexpr2xmltest.c, tests/statstest.c,
  tests/xencapstest.c, tests/xmconfigtest.c, tests/xml2sexprtest.c:
  Adapt to changed xen location
* src/stats_linux.h, src/stats_linux.c: Remove xen specific block
  stats APIs
* src/qemu_driver.c, src/uml_driver.c: Add missing sys/un.h include
  uncovered after change to stats_linux.h
* src/xen/block_stats.h, src/xen/block_stats.c: Add xen specific
  block stats APIs

* src/openvz_conf.c src/qemu_driver.c src/storage_backend_scsi.c
  src/xen_inotify.c: closes various file descriptors leaks

built-in TODO list for each driver.  Also rip out the internal getURI method;
it is never used by any of the drivers, and was buggy to boot.

* src/xen_inotify.c (xenInotifyXendDomainsDirLookup): Mark a diagnostic.
(xenInotifyXendDomainsDirRemoveEntry, xenInotifyOpen): Likewise.