“Docker Container: Stop” using command palette should only show running containers

[v-mengwe]

OS: All
Build Version: 20201114.1

Repro Steps:

1. Run "docker run hello-world" -> Make sure there is a stopped "hello-world" container.
2. Run "docker run registry" -> Make sure there is a running "registry" container.
3. Check the context menu of the stopped "hello-world" container -> Make sure there is no "Stop".
4. F1 -> Type "Docker Container: Stop" -> Select "Individual Containers" -> Check the listed result.

Expect:
There is no stopped "hello-world" container.

Actual:
There is a stopped "hello-world" container.

More Info:

1. This issue doesn't reproduce if there is no running container in the selected container group.
2. This issue also reproduces for GitHub Codespaces.

[bwateratmsft]

I can reproduce as long as multiple containers are running, I'll take a look.

[bwateratmsft]

It appears this is a regression from #2463. In the tree item picker logic in vscode-azureextensionui, it will always show parent tree items in the pick list (because you might be looking for a child of that tree item). In this case that is not true, but because ContainerTreeItem is now implemented as an AzExtParentTreeItem, that logic takes place.

@philliphoff I think we can solve this by implementing isAncestorOfImpl on ContainerTreeItem. I'm tempted to say it should always return false, but that would preclude the ability to use the command palette to get at files; only the explorer could be used. I'm OK with that, what do you think?

[philliphoff]

As a short-term measure, I think that's fine. We probably want to revisit the multi-item pick list logic in general as it doesn't seem to comprehend more nested structures; I thought I had worked around one issue with having containers now being a parent item, but evidently there are more.

Note that I'd hope that change would still support multi-select of files for opening (via the explorer). Not critical, though if that had to temporarily go.