Fixes failed open mount point when using file handles with chroot

When using a mount point as a shared directory (e.g. bind mount), using --sandbox=chroot and --inode-file-handles=mandatory/prefer, virtiofsd fails to open the mount point, with the following error:

[2022-06-03T15:44:22Z ERROR virtiofsd::passthrough] Filesystem mounted on "" (mount ID: 744): Failed to open mount point "": No such file or directory (os rror 2)
[2022-06-03T15:44:22Z ERROR virtiofsd] Failed to create internal filesystem representation: Os { code: 2, kind: NotFound, message: "No such file or irectory" }

When using --inode-file-handles=mandatory/prefer checks whether the root's (i.e. the shared directory) file handle is usable, calling check_working_file_handles() from within PassthroughFs::new(). To do this we need to determine the filesystem's mount point form the mount_id in /proc/self/mountinfo and open it. But, when using --sandbox=chroot, /proc/self/mountinfo still contains the pre-chroot mount point paths. To open filesystem's mount point, within 'get_mount_root()', we need to strip the shared directory as a prefix from it.

However, when the shared directory is a mount point (e.g. when is bind mounted) striping the shared directory from the filesystem's mount point:

    if let Some(suffix) = p.strip_prefix(prefix) {
         Ok(suffix.into())
    } else {
         Ok("/".into())
    }

the p.strip_prefix(prefix) call returns Some(""), because the shared directory and the filesystem's mount point are equal. And that means that get_mount_root() instead of returning Ok("\") it returns Ok("") that cannot be opened. A quick fix is to filter out "" to return None.

This is a temporal solution, a better solution, suggested by Vivek, is to open /proc/self, call chroot(shared_dir), and then open /proc/self/mountinfo using the previous /proc/self file descriptor. So, now the paths in /proc/self/mountinfo are relative to shared directory. This makes unnecessary the mountinfo_prefix logic. Since this solution requires a wider change and needs to be tested well to make sure we don't break any supported configuration, it will be implemented in a future MR.