As seen in [1], sometimes coreos/go-systemd/dbus package deadlocks: the
jobCompete is stuck trying to send job result string to the channel
while holding the jobListener lock, while startJob (called by
StartTransientUnit) waits for the same lock.

Alas, it is not clear why the channel is not being read, nor was I able
to reproduce it locally.

Make the job result channel buffered, so jobJistener won't block on
channel send and thus StartTransientUnit won't be stuck either.

While at it,

 - move the error wrapping out of mgr.RetryOnDisconnect function,
   and use fmt.Errorf with %w instead of obsoleted errors.Wrap;

 - improve error messages, printing the systemd unit name (so we can
   check it in systemd log);

 - do check the job result string -- in case it is not "done",
   return an error back to the caller, which should help avoid other
   issues down the line.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2082344

Signed-off-by: Kir Kolyshkin <[email protected]>