Only acquire workspace storage locks on the remote extension host

[alexdima]

In some cases, when the extension host is unresponsive, a window reload can lead to the new extension host process not being able to acquire the lock for workspace storage, since it is still held on by the old (unresponsive) extension host process (#128237).

There are even greater concerns that the current way to resolve lock contention (i.e. generating a fresh workspace storage folder e.g. ../${workspaceId}-1) is problematic if extensions store very important data in these folders. e.g. suppose a lock cannot be acquired, the workspace storage folder is changed to ../${workspaceId}-1, the extension writes very important data to ../${workspaceId}-1, VS Code is closed and reopened the next day, when the extension will end up using ../${workspaceId} as the workspace storage folder, missing out on the data written in ../${workspaceId}-1 (#128234).

As a low-risk band-aid, we can limit the acquiring of locks to only the remote extension host, where we have initially observed problems with multiple extension hosts sharing a single workspace storage folder, bringing the local extension host behavior back to what it was in 1.57.x and in the past.

[alexdima]

To verify:

• open a remote window.
• look at the local extension host log and check that it says Skipping acquiring lock...
• look at the remote extension host log and check that it says Acquiring lock...

[hediet]

The remote extension host log does not say Acquiring lock..., but instead Lock acquired.. I guess that counts too.

The local extension host reads Skipping acquiring lock for ....