VolumeManager: initialize even if a volume can't be found

VolumeManager: initialize even if a volume can't be found

If a previously volume cannot be exported (for example, because
an iSCSI target's backing LV is no longer present), VolumeManager
would previously bail out, leaving the volume service uninitialized.
This left volumes dangling in limbo: their state would be reported
as available (clearly not a reflection of reality), and they could
not be deleted (because the volume service that would be responsible
for deletion was unavailable).

Instead, catch an exception raised by ensure_export() separately,
log it, and set the volume to the error state.

For the tgt backend, this will also remove the volume_path file.
Previously this would cause an ISCSITargetRemoveFailed exception
when the volume would be removed. Instead, simply log a warning
and return, the way other backends (example: RBD) already do.

Also, add an info message that reflects the actual path and
contents of the volume_path file.

Finally, fix up the tgtadm unit test so that it tests for
identical IQNs,

Closes-bug: 1270959.

Change-Id: Id61407c9a5e020d5a823dd7b8c973d237c35cb9b