torture: Run durable_v2_reconnect_delay_msec with leases

torture: Run durable_v2_reconnect_delay_msec with leases

This will show a leases.tdb record leak. If you SIGSTOP the smbtorture
process while it's in the 10-second wait, you will find locking.tdb
and share_entries.tdb empty after the scavenger has cleaned up. But
there will be an entry in leases.tdb left.

I have no clue how to test this properly, or how to have a reasonably
cheap assert in smbd during normal operations. The problem is that
this leak can't really be distinguished from a "normal" leak that a
crashed smbd would leave behind. Possibly we need a background job
walking leases.tdb to clean this up properly.

Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>