refactor!: deprecate util.root_pattern

[dundargoc]

The primary (and potentially breaking) change is that
util.root_pattern traverses once per provided file pattern, while
vim.fs.find only traverses once. This means that the search will no
longer be prioritized by file order, which may break user configurations
who unkowingly rely on this behavior.

This will also be breaking for language servers that rely on code
dependencies that is archived but still needs to be read. More context:
#1687.

Work on #2079.

[dundargoc]

I couldn't come up with a good way to replicate the functionality provided by strip_archive_subpath so think we might just want to cut our losses here. @mfussenegger had a big brain suggestion about a related lsp feature that did something similar (by being able to read code from any URI or something?), so might want to use that in the future in core instead.

Found it: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.18/specification/#workspace_textDocumentContent

[justinmk]

Before merging this, let's wait a ~day to see if master is stable enough to tag a release.

Also: hoping that once we bump the minimum Nvim to 0.10, we can migrate these cases to vim.fs.root. If vim.fs.root doesn't work then we need to find out what it's missing ASAP :)

[dundargoc]

Looking more closely: I think vim.fs.find and util.root_pattern behaves differently in that find traverses once and root_pattern traverses once per provided filepattern, meaning that the ordering of the files used to matter. This would be a breaking change for users/configs unknowingly relying on this behavior, but it's impossible to say beforehand which servers it'd be without user input. I suggest we merge this anyway so we can at least evaluate the actual effect out there and react accordingly.

I'll add this info to the commit message as well.

[justinmk]

meaning that the ordering of the files used to matter.

Er, that's very much intentional: #2885

Changing it to "random" would be even worse than reverting that PR.

but it's impossible to say beforehand which servers it'd be without user input.

There was quite a lot of user input, and PRs, on this topic (unless I'm mistaken about #2885 being related).

Related?:

• Update util.rootpath to search all patterns per path => Fixes kotlin-ls root dir on multi-project builds #3321
• fix(lua_ls): return longest root path #3515

[dundargoc]

What about the following?

1. Add option in vim.fs.find for this functionality. As an example, python's os.walk has a topdown that adjust whether the traversal is breadth first or depth first. A similar option for vim.fs.find would suit it well I think.
2. Make it depth first by default for vim.fs.root so order matters.

This approach seems like the simplest way to move forward, but I understand if you're hesitant to add more options to vim.fs.find.

Edit: in the meantime, this problem can be worked around by doing multiple calls to vim.fs.find. Aka find(priority1) or find(priority2) or .... It's clunky but not super awful.

[justinmk]

What about the following?

Those SGTM.

Edit: in the meantime, this problem can be worked around by doing multiple calls to vim.fs.find. Aka find(priority1) or find(priority2) or .... It's clunky but not super awful.

Maybe we should keep root_pattern around for now. There's no real reason to avoid it until we have an answer in core.

[dundargoc]

Oof. I understand.

Closing for now until there's a solution in core as described in #3569 (comment).