Ensure workspace is read from WorkspaceContextService

[rothfels]

In most of the codebase (examples linked below), the services, parts, etc which depend on workspace context declare that through the dependency injection system, and always read workspace from the WorkspaceContextService (versus some cached instance state). This change replaces hard wires with getter method calls on the injected WorkspaceContextService, and prefers always using these method calls to read workspace. The primary motivation for the change is consistency.

Examples from past commits of the appropriate pattern:

• 6c45ea5#diff-3e8b9e83c7e6ca3ca4093f266f8b587eR32
• 0653833#diff-c93a0e42070e15efe5973a7aa2f71f53R382

[msftclas]

Hi @rothfels, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla.microsoft.com.

TTYL, MSBOT;

[msftgits]

Hi, I am closing and re-opening this PR to bump the CLA bot. Sorry for the inconvenience!

[msftclas]

Hi @rothfels, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!

The agreement was validated by Microsoft and real humans are currently evaluating your PR.

TTYL, MSBOT;

[jrieken]

The primary motivation for the change is consistency.

Not convinced that justified such a change.

[bpasero]

Me neither, I think it is fine to pass around workspace object instead of using the context service. Though in the future we might have to revisit this when we support multiple workspaces in one window.

[rothfels]

Not convinced that justified such a change.

Fair, though the secondary motivation is what @bpasero described. I figured this might not be on the roadmap so a consistency argument would make more sense. But for context, I'm running a patched version of vscode which loads a workbench in the user's web browser, similar to https://github.com/spiffcode/ghedit. We provide a "go-to-definition" feature which can navigate the user to a different workspace (e.g. for external dependencies). For the in-browser use case, we are forced to work with one window. Centralizing access to workspace state allows us in our patch to mutate that state exactly once.

I can see this change being unnecessary if you don't intend to support multiple workspaces in one window.

[bpasero]

LGTM, thanks.