See #4162 - Don't delay before deleting a file via SMB (psexec)

So I was looking at issue #4162, and on my box I was seeing this problem of the exploit failing to delete the payload in C:\Windows, and the error was "Rex::Proto::SMB::Exceptions::NoReply The SMB server did not reply to our request". I ended up removing the sleep(), and that got it to function properly again. It was specific to Win 7 SP1.

I also tested other Winodws boxes such as Win XP SP3, Windows Server 2008 SP2 and not having the sleep() doesn't seem to break anything. So I don't even know why someone had to add the sleep() in the first place.

## Verification

- [x] Make sure you have a Windows 7 SP1 box (32bit)
- [x] No firewall
- [x] In your registry, go to: ```HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System```, and then set ```LocalAccountTokenFilterPolicy``` to ```1```. If you don't have this DWORD key, add it.
- [x] Make sure you know the username/password of your box.
- [x] Start msfconsole
- [x] ```use exploit/windows/smb/psexec```
- [x] ```set SMBUSER [valid username]```
- [x] ```set SMBPASS [valid password]```
- [x] ```set verbose true```
- [x] ```run```
- [x] You should never see "Rex::Proto::SMB::Exceptions::NoReply" when the exploit is deleting the .exe file.

Note: This probably isn't a fix for #4162. Because as of now we're still unable to actually reproduce the exact same problem reported in that issue.