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

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. The box was a 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

- [ ] Make sure you have a Windows 7 SP1 box
- [ ] No firewall
- [ ] 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.
- [ ] Make sure you know the username/password of your box.
- [ ] Start msfconsole
- [ ] ```use exploit/windows/smb/psexec```
- [ ] ```set SMBUSER [valid username]```
- [ ] ```set SMBPASS [valid password]```
- [ ] ```run```
- [ ] 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.