[WIP] config: Normalize internal volumes path on Windows.

[Dimrok]

See docker/for-win#1829.

Basically, bind mounts using UNIX paths are not valid when running docker-compose on Windows when running Docker for Windows unless COMPOSE_CONVERT_WINDOWS_PATH is set.

This PR solves the problem by forcing the denormalization of the internal paths if the running platform is Windows or if COMPOSE_FOR_WINDOWS_HOST is set (not just if COMPOSE_CONVERT_WINDOWS_PATH is set).

Given docker-compose.yml:

version: '3'
services:
    service:
        image: docker
        stdin_open: true
        tty: true
        volumes:
            - /var/run/docker.sock:/var/run/docker.sock 

Previous behavior

> docker-compose.exe version
docker-compose version 1.22.0, build f46880fe
docker-py version: 3.4.1
CPython version: 3.6.6
OpenSSL version: OpenSSL 1.0.2o  27 Mar 2018
> docker-compose.exe up
Recreating service_1 ... error
 
ERROR: for service_1  Cannot create container for service docker: b'Mount denied:\nThe source path "\\\\var\\\\run\\\\docker.sock:/var/run/docker.sock"\nis not a valid Windows path'
 
ERROR: for docker  Cannot create container for service docker: b'Mount denied:\nThe source path "\\\\var\\\\run\\\\docker.sock:/var/run/docker.sock"\nis not a valid Windows path'
ERROR: Encountered errors while bringing up the project.

Path /var/run/docker.sock is converted to \\var\\run\\docker.sock and Docker for Windows cannot find this path.

New behavior

> docker-compose.exe up
Creating service_1 ... done
Attaching to service_1

Path /var/run/docker.sock is reconverted from \\var\\run\\docker.sock back to /var/run/docker.sock which is intelligible for Docker for Windows.

Concerns

Or:

• We should not convert the path in the first place making the user responsible for the targeted host platform.
• What about docker machine?
• We could query the host and convert the paths accordingly.

Resolves docker/for-win#1829

[shin-]

@Dimrok thanks for the submission!

I only took a quick look, but I have concerns about the approach. The point of COMPOSE_FORCE_WINDOWS_HOST was to allow users with a UNIX laptop to deploy with Compose on a Windows Server (i.e. with Windows paths on the daemon host, but with the Compose client installed on a UNIX system). So I think tying this behavior to this environment variable is the wrong direction.

I'll follow up with the direction I think we should take later when I've had time to look at all this more carefully.

[Dimrok]

Closing this PR because #6204 is a better way of fixing the issue.