s4:torture/smb2: add smb2.multichannel.oplocks.test3{_windows,specification}

s4:torture/smb2: add smb2.multichannel.oplocks.test3{_windows,specification}

This is similar to the smb2.multichannel.leases.test5,
but it tests the oplock case instead of leases.

With Oplocks Windows only sends a single break on the latest channel,
this is not what the spec says...

Maybe we should have a similar test that would expect the
behavior from the [MS-SMB2] (3/4/2020 rev 60.0)
"3.3.4.6 Object Store Indicates an Oplock Break":

  ...

  If the server implements the SMB 3.x dialect family, SMB2 Oplock Break
  Notification MUST be sent to the client using the first available
  connection in Open.Session.ChannelList where Channel.Connection is not
  NULL. If the server fails to send the notification to the client, the
  server MUST retry the send using an alternate connection, if available,
  in Open.Session.ChannelList.
  ...

Here I add one test that demonstrates the Windows behavior:
 smb2.multichannel.oplocks.test3_windows
and a 2nd test that demonstrates the behavior from MS-SMB2.
 smb2.multichannel.oplocks.test3_specification

Note that Windows 10 seems to behave differently and it's not
possible to open all 32 channel used by this test.

Against remote servers it's required to run iptables as root:

 #> smbtorture //server/torture -Uu%p \
    --option="torture:use_iptables=yes" \
    --option="torture:iptables_command=sudo /sbin/iptables" \
    smb2.multichannel.oplocks.test3_windows

 #> smbtorture //server/torture -Uu%p \
    --option="torture:use_iptables=yes" \
    --option="torture:iptables_command=sudo /sbin/iptables" \
    smb2.multichannel.oplocks.test3_specification

The test will also work against a Samba server
with 'smbd:FSCTL_SMBTORTURE = yes', and won't require iptables
in that case.

Samba will get a "smb2 disable oplock break retry" configuration
option to switch between both behaviors, as it's much more common with Samba
that leases are not supported and clients will fallback to
oplocks together with multichannel.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=11897

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Günther Deschner <gd@samba.org>