RFC: s3/smbd: change locking behavior when "lock spin time = 0"

[Steven Danneman]

> > This is useful for naughty clients who spam the server with trylocks
> and
> > don't want to be slowed down.  Specifically, I'm using this for a
> client
> > application that will send 20 trylocks in a row when it's
contending.
> > With the default setting this causes it to wait for several seconds.
> >
> >
> >
> > Any comments before I check-in?
> 
> I trust you, I'm sure it's right. But I'm going to read it *very*
> carefully after it's in :-). Can you say what the application is ?
> 
> Jeremy.

Please do :).  I had to read ALL of the locking code very carefully to
come upon this fix.  

I honestly can't say what the name of the application is because I don't
know but this was a simple case of "performance was good on Samba 3.0,
performance sucks on Samba 3.4".  The reason turned out to be the
implementation of the correct Windows LockViolationDelay semantics.

So in 3.0 a client that sent the same contending locking request 20
times in a row would get NT_STATUS_LOCK_CONFLICT returned in about 1ms
each, totaling 20ms delay.  In 3.4 each of these locks would pause
server side for 250ms, making the client wait for ~5 seconds before
continuing.

So this patch really just gives the ability to revert to the 3.0
behavior if an admin doesn't mind having the server spammed by locking
requests.

-Steven