fc_rport_logoff drops the rport lock in order to cancel work
that may be pending.  This is undesirable as the state can
completely change, and the caller may not expect that the
lock could've been dropped.

If there is work pending, it will acquire the rdata mutex and
so we're protected and can change the event from READY to DELETE.
Queue the work only if there is no event already pending.

There were a couple other cases where the state was set to
DELETE and work queued, even though the state may have already
been DELETE.  Fix these using a common function fc_rport_enter_delete().
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>