### Proposal In https://gitlab.com/gitlab-org/gitlab/-/merge_requests/61380 we expose path locks in the graphql API. Currently, there is no REST API support for them - only a Rails controller that is oriented to operating on individual path locks. This results in N+1 issues when trying to work on several paths at a time in the current frontend. The repository view is being refactored to use graphql, so we don't really need the REST API, but the implementation going in doesn't allow us to filter path locks by path. They're not a well-used feature, but in cases where a repository has a great many path locks, this leads to inefficiencies and unnecessary frontend work. We should add the following arguments to the graphql API for path locks: * `paths` * `exact_match` * `downstream` The first is an array of strings, which filter the path locks we'll return by path. The latter two are booleans that alter the meaning of the paths - if `exact_match` is `false`, then we'll return a path lock of, say, `app/` when the path is `app/models/project.rb`. If `downstream` is true, we'll return a path lock of, say, `app/models/project.rb` when the path is `app/`. Currently, path locks are filtered by `Gitlab::PathLocksFinder`, which is oriented to finding a single path lock at a time, so it's not suited for the new GraphQL API. As part of this, we'll need to make this into a "proper" finder and refactor the existing users to cope.