Enrich Git extension's remote source provider API

[joyceerhl]

Re: #141295

This pull request expands the remote source provider API from the git-base extension, allowing any extension to provide remote sources with the same richness that is currently available in the Remote Repositories extension. Since we're enriching the API in git-base, I think it also makes sense to rework Remote Repositories to take advantage of this API instead of having its own picker.

The key changes are:

• Rework the remote source picker flow to allow RemoteSourceProvider.getSources() to display the provider's own secondary quickpick before returning a list of RemoteSources.
  • This enables Azure Repos to display its pickers for selecting an organization and project inside the getSources() method before generating a list of repositories.
• Allow callers of the getRemoteSources API command to customize the title and placeholder of the quickpick, in addition to the provider label.
  • This lets Remote Repositories continue using its current title and placeholder.
• Allow callers of the getRemoteSources API command to customize the URL label for a given URL.
  • Consumers can use this function to display more informative labels for URLs pointing to a repository, pull request, branch, tag, file etc., which Remote Repositories already does today.
• Allow remote source providers to specify a quickpick placeholder.
  • This is necessary so that e.g. GitHub Repositories can contribute a remote source provider for GitHub pull requests and have the quickpick placeholder talk about pull requests instead of repositories.
• Allow remote sources to specify a detail in addition to the description.
  • This is necessary so that GitHub Repositories' remote source provider can include the star count / fork information next to the repository name and the repo description in the detail.
  • I also updated the builtin GitHub extension's usage of the getRemoteSources API command to align it with the experience in the GitHub Repositories extension.
• Introduce the concept of a recent remote source. Recent sources are displayed in the same list as the remote source providers.
  • This enables parity with the existing Remote Repositories experience, where there is a list of recently opened items in the top-level picker.
  • Maybe we should make displaying the recent sources opt-in by the caller of getRemoteSources, so that these do not appear in unexpected locations where getRemoteSources is being used and where the Remote Repositories extension has activated for some reason (e.g. user clicks Open Remote Repositories which activates Remote Repositories, then triggers getRemoteSources through some other extension).

While adopting some of these API changes in the builtin GitHub extension, I also encountered and fixed #123986 by always including fork:true in the search query. I fixed this exact issue in Remote Repositories some time back.

Some remaining questions I have:

• We don't have the ability to display fork info in the builtin GitHub extension, since it relies on the REST APIs for getting repository info, and that would necessitate an additional API call for each forked repository in order to determine the parent. Let me know if you think it would be good to make that change.
  • If we add this, the builtin GitHub extension's remote source provider will have full feature parity with the GitHub Repositories remote source provider for repositories. We could enable the builtin GitHub extension in virtual workspaces and remove the GitHub Repositories version.
• Currently GitHub Repositories displays an inline item when there are additional SAML-protected results, with a showMore method that when clicked initiates reauthentication. @lszomoru I wanted to get your thoughts on adding this to the API since it is pretty specific. An alternative is that GitHub Repositories could just do an authentication.getSession with forceNewSession: true when we get truncated results due to missing SSO.

[lszomoru]

These changes look good to me but I would like @joaomoreno to have a quick look as well.

[joaomoreno]

We don't have the ability to display fork info in the builtin GitHub extension, since it relies on the REST APIs for getting repository info, and that would necessitate an additional API call for each forked repository in order to determine the parent.

But those calls would slow down showing the entire list, right? Is that how the GitHub Repositories does it today?

remove the GitHub Repositories version

❤️

with a showMore method that when clicked initiates reauthentication

Is this displayed as an inline action on the quick open item?

[joyceerhl]

Is that how the GitHub Repositories does it today?

GitHub Repositories uses the GraphQL API to search for Repository objects, so it can retrieve the fork parent (if any) with a single network request. This information isn't available without a second call through the REST API. Though it's also true that the GraphQL API might be slower, so even if we switched the GitHub extension over to use the GraphQL API, we might slow down the list generation overall.

Is this displayed as an inline action on the quick open item?

Yeah, the motivation is that users are already looking at the quickpick and wouldn't notice if we displayed a notification in the bottom right about the incomplete results. From talking with @lszomoru I think we want to avoid introducing this into the API unless we hear a real need for it, and GitHub Repositories has an alternative today (which is to immediately ask for auth as soon as we detect missing SAML--it's a degraded experience compared to now because the user has less context on why they're being asked to reauthenticate, but it's also strange that we would put actions inline in the quickpick).