So there are couple of issues here. Firstly, we never unref the
@pendingReply and thus it leaks.

==13279== 144 (72 direct, 72 indirect) bytes in 1 blocks are definitely lost in loss record 1,095 of 1,259
==13279==    at 0x4C2E080: calloc (vg_replace_malloc.c:711)
==13279==    by 0x781FA97: _dbus_pending_call_new_unlocked (in /usr/lib64/libdbus-1.so.3.14.11)
==13279==    by 0x7812A4C: dbus_connection_send_with_reply (in /usr/lib64/libdbus-1.so.3.14.11)
==13279==    by 0x56BEDF3: virNetDaemonCallInhibit (virnetdaemon.c:514)
==13279==    by 0x56BEF18: virNetDaemonAddShutdownInhibition (virnetdaemon.c:536)
==13279==    by 0x12473B: daemonInhibitCallback (libvirtd.c:742)
==13279==    by 0x1249BD: daemonRunStateInit (libvirtd.c:823)
==13279==    by 0x554FBCF: virThreadHelper (virthread.c:206)
==13279==    by 0x8F913D3: start_thread (in /lib64/libpthread-2.23.so)
==13279==    by 0x928DE3C: clone (in /lib64/libc-2.23.so)

Secondly, while we send the message, we are suspended ('cos we're
talking to a UNIX socket).  However, until we are resumed back
again the reply might have came therefore subsequent
dbus_pending_call_set_notify() has no effect and in fact the
virNetDaemonGotInhibitReply() callback is never called. Thirdly,
the dbus_connection_send_with_reply() has really stupid policy
for return values. To cite the man page:

  Returns
      FALSE if no memory, TRUE otherwise.

Yes, that's right. If anything goes wrong and it's not case of
OOM then TRUE is returned, i.e. you're trying to pass FDs and
it's not supported, or you're not connected, or anything else.
Therefore, checking for return value of
dbus_connection_send_with_reply() is not enoguh. We also have to
check if @pendingReply is not NULL before proceeding any further.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>