add workaround for Windows/IIS6 FTP server strangeness causing unlock failures.

So we did a log of this on IRC with -Dtransport. This shows the held->tmp rename succeeding, a nd the subsequent
rm tmp/info
rmd tmp
succeeding too, but the lock remains in place.

my theory is a virus scanner or some such interfering.

Some things we can do to narrow it down:
-add a read-back after the rename to make sure it does rename away successfully.

Something we did:
-tried a 2s delay before the rename, but this didn't appear to have any effect.

modified unlock method in lockdir for debugging

            # gotta own it to unlock
            self.confirm()
            print "waiting two seconds"
            time.sleep(2)
            for pos in range(10):
                try:
                    if pos:
                        self.confirm()
                except LockBroken:
                    print "pre-rename missing lock ", i
                    break
                except Exception, e:
                    print "pre-rename fail: ", e
                    raise
                try:
                    self.transport.rename(self._held_dir, tmpname)
                except Exception, e:
                    print "fail: ", e
                    raise
                time.sleep(1)
                try:
                    self.confirm()
                except LockBroken:
                    print "rename-to-unlock successful"
                    break
                except Exception, e:
                    print "confirm fail: ", e
                    raise
                else:
                    print "ftp breakage"
            print "past unlock step"
            self._lock_held = False
            self.transport.delete(tmpname + self.__INFO_NAME)

The attachd files add enough data that you can use the StringO stuff in the log trace + the network trace to make a test - put the strings that are uploaded on disk as files with the right names so you can
put branch-lock/tmp.../info
rename branch-lock/tmp... branch-lock/held
etc.

The goal is now to demonstrate the problem clearly outside of bzr.

Attached is a script file for the Windows command-line FTP client, which reproduces this precise issue.

In general, the result is that the script suceeds in retrieving the info file with the final get command - it clearly should not, because it's parent folder ought to have previously been renamed and deleted. The log produced in this case is the following:

230 User alexreg-repos logged in.
ftp> mkd /texdotnet
257 "/texdotnet" directory created.
ftp> mkd /texdotnet/.bzr
257 "/texdotnet/.bzr" directory created.
ftp> mkd /texdotnet/.bzr/branch-lock
257 "/texdotnet/.bzr/branch-lock" directory created.
ftp> mkd /texdotnet/.bzr/branch-lock/0u7zlmi2ue.tmp
257 "/texdotnet/.bzr/branch-lock/0u7zlmi2ue.tmp" directory created.
ftp> put info /texdotnet/.bzr/branch-lock/0u7zlmi2ue.tmp/info
200 PORT command successful.
150 Opening ASCII mode data connection for /texdotnet/.bzr/branch-lock/0u7zlmi2u
e.tmp/info.
226 Transfer complete.
ftp: 115 bytes sent in 0.14Seconds 0.82Kbytes/sec.
ftp> rename /texdotnet/.bzr/branch-lock/0u7zlmi2ue.tmp /texdotnet/.bzr/branch-lo
ck/held
350 File exists, ready for destination name
250 RNTO command successful.
ftp> get /texdotnet/.bzr/branch-lock/held/info info-got
200 PORT command successful.
150 Opening ASCII mode data connection for /texdotnet/.bzr/branch-lock/held/info
(115 bytes).
226 Transfer complete.
ftp: 115 bytes received in 0.00Seconds 115000.00Kbytes/sec.
ftp> rename /texdotnet/.bzr/branch-lock/held /texdotnet/.bzr/branch-lock/releasi
ng.jxclhhpmuppakcm6gbz7.tmp
350 File exists, ready for destination name
250 RNTO command successful.
ftp> delete /texdotnet/.bzr/branch-lock/releasing.jxclhhpmuppakcm6gbz7.tmp/info
250 DELE command successful.
ftp> rm /texdotnet/.bzr/branch-lock/releasing.jxclhhpmuppakcm6gbz7.tmp/info
550 /texdotnet/.bzr/branch-lock/releasing.jxclhhpmuppakcm6gbz7.tmp/info: The sys
tem cannot find the file specified.
ftp> rmd /texdotnet/.bzr/branch-lock/releasing.jxclhhpmuppakcm6gbz7.tmp
250 RMD command successful.
ftp> get /texdotnet/.bzr/branch-lock/held/info
200 PORT command successful.
150 Opening ASCII mode data connection for /texdotnet/.bzr/branch-lock/held/info
(115 bytes).
226 Transfer complete.
ftp: 115 bytes received in 0.00Seconds 115000.00Kbytes/sec.
ftp> quit
221

As previously suggested, this would seem to imply one of two things:
* The rename and/or delete commands report success before their operations have actually concluded.
* The directory that exists before the rename/delete is cached, and the FTP server is using this cache for the final get command, hence its unexpected success.

On many occasions however, the script does not even finish, seemingly due to a failed attempt to open a data connection.

230 User alexreg-repos logged in.
ftp> mkd /texdotnet
257 "/texdotnet" directory created.
ftp> mkd /texdotnet/.bzr
257 "/texdotnet/.bzr" directory created.
ftp> mkd /texdotnet/.bzr/branch-lock
257 "/texdotnet/.bzr/branch-lock" directory created.
ftp> mkd /texdotnet/.bzr/branch-lock/0u7zlmi2ue.tmp
257 "/texdotnet/.bzr/branch-lock/0u7zlmi2ue.tmp" directory created.
ftp> put info /texdotnet/.bzr/branch-lock/0u7zlmi2ue.tmp/info
200 PORT command successful.
150 Opening ASCII mode data c...

There isn't really anything sensible bzr can do to fix this, downgrading to wishlist, as I'm told that an upgrade to windows 2008 + IIS7 has fixed the users specific problem (though other folk could run into the same issue).