s4:torture/smb2: make smb2.lock.replay_broken_windows more obvious

s4:torture/smb2: make smb2.lock.replay_broken_windows more obvious

This test check the SMB 2.1.0 behaviour of lock sequence checking,
which is only turned on for resilient handles.

Even Windows Server 2019 only implements lock sequence checking only
for resilient and persistent handles as a server.
While its client side uses lock sequence checking if it negotiated
multichannel with the server.

Hopefully this will be fixed in future Windows versions.

Make it clear that this test is supposed to pass against the legacy
Windows servers which violate the specification:

  [MS-SMB2] 3.3.5.14 Receiving an SMB2 LOCK Request

  ...

  If the LockSequence value in the SMB2 LOCK Request (section 2.2.26) is not zero,
  and either one of the following conditions is TRUE, the server SHOULD verify
  whether the lock/unlock request with that LockSequence value has been
  successfully processed before:
  * Connection.Dialect is "2.1" and Open.IsResilient is TRUE.
  * Connection.Dialect belongs to the SMB 3.x dialect family.<318>

  ...

  <318> Section 3.3.5.14: Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012
  R2 do not verify the LockSequence value in the SMB2 LOCK Request (section 2.2.26) when both
  Open.IsResilient and Open.IsPersistent are FALSE.

Note <318> also applies to Windows Server 2016 and 2019.

Signed-off-by: Stefan Metzmacher <metze@samba.org>