s3/librpc: open_files.idl: updates for Persistent Handles

s3/librpc: open_files.idl: updates for Persistent Handles

New share_mode_entry flag:
- SHARE_ENTRY_FLAG_PERSISTENT_OPEN

New share_mode_data member:
- num_persistent

New share_mode_entry members:
- create_guid
- protect

delete_token
- open_persistent_id

New vfs_default_durable_cookie members:
- initial_delete_on_close

The SHARE_ENTRY_FLAG_PERSISTENT_OPEN flag is crucially needed to modify the
behaviour of share_entry_stale_pid() and used in other places when looking at a
share_mode_entry and having to adust processing behaviour for Persistent
Handles.

num_persistent is used to track the number of Persistent Handles per
share_mode_data record, adjusting dbwrap_store() behaviour depending on its
value: if num_persistent is greater then zero, we pass DBWRAP_STORE_PERSISTENT.
Without it we would have to iterate over oll share_mode_entry's every time we
store the record.

The create_guid ties together the open state from locking.tdb and the
smbXsrv_open_global.tdb as an additional hardening to securely corolate both.

The protect boolean is an in-memory flag indicating a disconnected Persistent
Handle. We don't want to store this in the share_mode_entry on disk.

open_persistent_id in the delete_token will be used to implement scavening
delete_tokens when Persistent Handles with delete-on-close set expire. Windows
will actually delete the file, but this is not easily possible with the current
architecture of the scavenger, but we must at least correctly remove those stale
tokens.

initial_delete_on_close is used to preserve the fsp flag initial_delete_on_close
across disconnects. When reconnecting the handle, the fsp flag can be
reestablished based on the value from the cookie.

Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Anoop C S <anoopcs@samba.org>