filesystems mounted within an SMB share and REPARSE_TAG_MOUNT_POINT

[Andrew Walker]

I was recently reviewing fileid behavior in Samba for ZFS datasets mounted
within an SMB share and decided to see how a Windows server handles such a
situation (by mounting a separate NTFS volume within an SMB share on Server
2022 and poking around at it). I can provide pcaps for the morbidly curious.

SUBDS on Windows Server:
```
PS C:\SHARE> Get-Item .\SUBDS | format-list


    Directory: C:\SHARE



Name           : SUBDS
CreationTime   : 2/22/2023 10:45:52 AM
LastWriteTime  : 2/22/2023 10:45:52 AM
LastAccessTime : 2/22/2023 10:45:52 AM
Mode           : d----l
LinkType       : Junction
Target         : {Volume{5afcf2e4-f78f-4931-bfb1-a657a2577d06}\}
```

SMB2 QUERY_DIRECTORY with FileIdBothDirectoryInfo has
FILE_ATTRIBUTE_REPARSE_POINT set as well as REPARSE_TAG_MOUNT_POINT.
```
FileIdBothDirectoryInfo: SUBDS
    Next Offset: 0
    File Index: 0x00000000
    Create: Feb 22, 2023 10:45:52.500407200 Pacific Standard Time
    Last Access: Feb 22, 2023 10:45:52.500407200 Pacific Standard Time
    Last Write: Feb 22, 2023 10:45:52.500407200 Pacific Standard Time
    Last Change: Feb 22, 2023 10:45:56.880741900 Pacific Standard Time
    End Of File: 0
    Allocation Size: 0
    File Attributes: 0x00000410
    Filename Length: 10
    Reparse Tag: REPARSE_TAG_MOUNT_POINT (0xa0000003)
    Short Name Length: 0
    Reserved: 00
    Reserved: 0000
    File Id: 0x001e00000000b590
    Filename: SUBS
```

FILE_ATTRIBUTE_REPARSE_POINT is also set in File Attributes on SMB2 CREATE
response.

Samba currently uses the device ID and inode number to generate 64-bit file
ids in subordinate filesystems within an SMB share, but it seems like this
can lead to potential collisions. Windows, for instance, appears to make no
change to the 64-bit file IDs returned for NTFS volumes mounted within an
SMB share.

So this is a long way of asking, should we be flagging mounted filesystems
as reparse points and not altering the inode numbers?

The advantages of this are:
1. Windows File Explorer GUI clearly labels as a mounted filesystem and not
a directory
2. Windows File Explorer GUI clearly shows size of the filesystem
separately from one being shared.
3. REPARSE_TAG_MOUNT_POINT can be used by SMB clients to judge whether the
particular fileid should maybe be treated differently (since it may collide
with other volume mountpoints). (not sure if any non-MS clients do this).

Andrew