Revert "ib_srp: Keep processing commands during scsi_remove_host()"

This reverts commit 5d09ad00abfb7a4969b906785210560fec702d85.

This revert fixes a problem upon removing an SRP target when the SRP
target machine crashed accidently without giving back any IB events. In
that case, the admin cannot make use of deleting remote ports for the
purpose of tearing down SRP targets as well as SCSI host.

Its reason was SRP commands being queued even if target had already been
deleted. Consequence was unfortunately hanging forever, until the target
machine comes up again after having rebooted. Precisely it's blocked on
scsi_execute() directly after sending SYNCHRONIZE_CACHE command.
As IB stack is not able to return anything, further device delete
actions cannot be procssed starting from that.

That symptom is simply reproducible via sysfs. First of all, trigger an
immediate reboot via /proc/sysrq-trigger on the SRP target.

  target# echo b > /proc/sysrq-trigger

After doing that, the Infiniband connection will be completely gone for
several minutes at least. Then on the initiator's side, delete a remote
port by writing 1 to /sys/class/srp_remote_ports/port-*\:1/delete, e.g.:

  initiator# echo 1 > /sys/class/srp_remote_ports/port-6\:1/delete

, where the SRP remote port to be deleted has its number 6.

Then you will see stale SCSI targets remaining despite of rport delete,
which is not expected though. That was resulted from device_del()
hanging forever on upon calling scsi_execute() with SYNCHRONIZE_CACHE.

This revert makes sense only for kernel 3.4.x with srp-ha v4 or older.
Since srp-ha v5 the commit to be reverted does not exist at all.
Apparently kernel 3.6 or higher does not have such blocking issue,
even without reverting the commit.