Implementing jumping to location when clicking on a usage in the details panel

[robertbrignull]

The feature being implemented here is that you can click on an entry in the CodeQL model details panel and it'll open that code location in the main editor. This doesn't implement selecting the correct usage when clicking on the "view" button and that will be a different PR.

I've implemented this using a new codeQLDataExtensions.jumpToUsageLocation command. I did first try out using vscode.open and passing it a URI, but sadly I don't believe we can use that. Instead we can call the existing showResolvableLocation method, but making that work involves a few steps:

• We'd like some error handling, and we currently already perform this same error handling in two places. I move the error handling to be inside showResolvableLocation so we avoid duplication.
• We need the DatabaseItem to be able to resolve the code location to a file that can be displayed in the editor. This means that we need to pass the database item to the ModelDetailsDataProvider class along with the ExternalApiUsage[] array. I think it makes sense to set these together because you need both to be in sync in order to resolve locations correctly.

Checklist

• CHANGELOG.md has been updated to incorporate all user visible changes made by this pull request.
• Issues have been created for any UI or other user-facing changes made by this pull request.
• [Maintainers only] If this pull request makes user-facing changes that require documentation changes, open a corresponding docs pull request in the github/codeql repo and add the ready-for-doc-review label there.

[charisk]

Thank you for splitting into sensible commits - it made reviewing much easier 🎉

I've got a couple of non-blocking comments.

[charisk]

Should the command be codeQLDataExtensionsEditor as it's not general to data extensions? I don't have a strong opinion - just a thought really.

[robertbrignull]

Good point. I was more trying to match the naming scheme of the files for the module, but either way codeQLDataExtensionsEditor is a better name.

[charisk]

This surprised me a little bit. I've generally thought of the "DataProvider" classes as the ones managing state and expected the data extensions editor view to use the provider rather than the panel. Having said that, I can't think of a problem with what you've done here 🤔

[robertbrignull]

I guess it depends whether you think of the data provider as the public interface to the panel or as an internal detail. Personally I think of them as more internal, but I'm also happy with either option.

Currently the data provider is constructed and owned by the panel. We could have it be constructed outside and passed into the panel. Then the panel is literally nothing more than a single call to window.createTreeView.

Currently the panel is constructed from DataExtensionsEditorModule and there isn't a separate "module" just for the detail panel. So in this case I think it's better to have the data provider be constructed inside ModelDetailsPanel as it keeps things slightly contained without introducing another "module" class which would itself be tiny.

[charisk]

Cool! Lets go with that and see if we can identify any pros/cons about either approach. In general it feels like it would be good to standardise a bit to make the codebase a bit easier.