storage: Fix issue finding LU's when block doesn't exist
    
    Fix a problem in the getBlockDevice and processLU where retval initialized
    to zero causing some failures to erroneously continue through to the
    virStorageBackendSCSINewLun with an attempt to find a path for "/dev/(null)".
    This would fail approximately 10 seconds later with debug message:
    
    virStorageBackendSCSINewLun:203 :
         No stable path found for '/dev/(null)' in '/dev/disk/by-path'
    
    The root cause of the issue is for many /sys/bus/scsi/devices/<lun path>
    there is no "block*" device found for the vHBA's, where "<lun path>" are
    the various paths created for the vHBA, such as "17:0:0:0", "17:0:1:0",
    "17:0:2:0", "17:0:3:0", etc.  If the block device isn't found, then the
    directory should just be ignored rather than attempting to process it.
    
    The bug was that in getBlockDevice the assumption was "block" would exist
    and either getNewStyleBlockDevice or getOldStyleBlockDevice would fill in
    @block_device. However, if 'block*' doesn't exist, then the code returned
    NULL for block_device *and* a good (zero) retval value.  This caused the
    processLU code to attempt the virStorageBackendSCSINewLun which failed
    "at some point in time" in the future.
    
    After this change - on test system the refresh-pool didn't have a noticable
    pause of about 20 seconds - it completed within a second since no longer
    was there an attempt/need to find "/dev/(null)".
    
    Additionally, the virStorageBackendSCSIFindLU's shouldn't be declaring
    found unless the processLU actually returns success. This will be
    important in the followup patch which relies on whether a LU was found.