Don't use findTreeItem in AzExtTreeFileSystem

[alexweininger]

We haven't gotten findTreeItem to work for v2 yet since tree item IDs haven't been ironed out. However, I'm proposing that we move away from using findTreeItem in AzExtTreeFileSystem. AzExtTreeFileSystem is one of the main places where findTreeItem is used.

vscode.FileSystemProvider relies on handling Uris within VS Code. Within the file system provider methods we need access to the tree item in order to read/write the file content. Currently, we're adding the tree item ID to the Uri query params, and then using findTreeItem to retrieve the tree item within the handler.

Although that works great, I found it sorta wasteful to use findTreeItem to retrieve a reference to an object that we already have when forming the Uri. Instead, I just store the tree item in a Map with a random key and pass the key in the Uri, eliminating the need for findTreeItem. This method is probably a bit faster too.

Drawbacks of this method include:

• File system provider will not be able to handle URIs that have originated from this method and have tree items in the Map. This is fine since we currently don't support this anyway.

[nturinski]

Should we clear and repopulate this every time a refresh happens? Seems like it could cause stale tree item ids if we're not careful.

[alexweininger]

I haven't run into that in my testing, but I am worried about the possibility of something like that happening. The tree item ids correspond to Azure resource ids so unless something is deleted I think it's fine. I will test that now. I don't know if delete was handled properly in v1.

If you delete a resource while editing the tags it will show this error. I think that's fine behavior.

[alexweininger]

Also whenever I tried clearing this map, it resulted in errors since we can't really know if the items in the map are still in use easily.

[alexweininger]

A potential fix for all of this would be to really remove the reliance on items at all, and base if fully on URIs.

[nturinski]

Oh, this is only for the FileSystem? So findTreeItem will still be used in normal TreeDataProviders?

[alexweininger]

Oh, this is only for the FileSystem? So findTreeItem will still be used in normal TreeDataProviders?

Yes this PR is only removing the usage of findTreeItem (and anything AzExtTree* related for that matter) from the file system. Side note: maybe we should rename this class...

However, findTreeItem is still used in other places in the v1.5 client extensions. But we are not exposing a find API in v2. At least not yet. There's a chance we absolutely must add it when upgrading v1.5 extensions to v2. However we want to avoid this as much as we can because the whole find tree item thing is a bit problematic.