ls: handle broken symlink

[pared]

Fixes: #7120

• ❗ I have followed the Contributing to DVC checklist.

• 📖 If this PR requires documentation updates, I have created a separate PR (or issue, at least) in dvc.org and linked it here.

Thank you for the contribution - we'll try to review it as soon as possible. 🙏

[efiop]

Note that you are ignoring FileNotFoundError if dvc_only, which could be a dangerous bug. Also duplicating code, so how about smth like:

        try:
            metadata = fs.metadata(info)
        except FileNotFoundError:
            if dvc_only:
                raise
                
            metadata = Metadata()
            
        if metadata.output_exists or not dvc_only:
            path = (
                fs.path.name(fs_path)
                if fs_path == info
                else fs.path.relpath(info, fs_path)
            )
            ret[path] = {
                "isout": metadata.is_output,
                "isdir": metadata.isdir,
                "isexec": metadata.is_exec,
            }

[efiop]

Btw, how does CLI ls handle broken symlinks? Should we colorize it too? If so, how hard would that be?

[pared]

Btw, how does CLI ls handle broken symlinks? Should we colorize it too? If so, how hard would that be?

CLI ls handles it the same way as symlinks - we get a color for symlink.
I think that we should not consider that in that in this change: so far we haven't been differentiating between files/dirs and links.

We could consider implementing it. The problem with that is that currently, we are differentiating the colors by determining whether the target is output/dir/executable. If none of the above, we use an extension to determine it. So far there has been no talking about links. In order to provide support, we would need to pass islink returned by fsspec.info up to the Metadata and leverage it to assign a color.

The question is whether we should do that. CLI ls is about inspecting the filesystem so it makes sense to mark the links. However the DVC is about our ML project - the most important is to differentiate between tracked and non tracked assets. I think w should not expand that. Even now, the behavior might be a bit counterintuitive. For example: if our pipeline will be producing executable, it will still be colored as output, because it is the first check we do. I think in this case we should not follow ls style.

As an alternative, we could consider how to "mix" colors depending on the multiple properties of a given asset.

[pared]

With the current approach (creating empty Metadata) I think it makes sense to remove this check.
it shouldn't matter if we use dvc_only or not. In my initial version lack of this was a bug, silently skipping the error, but now it seems ok to remove it. Users should not be punished for a specific check. If there is a broken symlink, other commands will make sure of erroring out

[pared]

Also, in the case of dvc_only files, we should never get here: repo_fs will be able to get the metadata even for the removed file