Enhancement: add proxy configuration to contexts

The docker cli allows configuring proxy servers to be used when creating containers (I don't think services/stacks currently use this feature, but that could be something to consider). This feature was implemented in https://github.com/docker/cli/pull/93 (Docker 17.07).

The existing feature allows you to define which proxies should be used for a specific connection

For example, the following example defines which proxies to use when deploying a container on development.corp.example.com or production.corp.example.com, but on any other connection ( default), no proxies will be used.

{
  "proxies": {
    "default": {
    },
    "tcp://development.corp.example.com:2376": {
      "HTTPProxy" :"http://dev-proxy.example.com:3128",
      "HTTPSProxy" :"https://user:password@dev-proxy.example.com:3129",
      "FTPProxy" :"http://dev-ftpproxy.example.com:21",
      "NoProxy" :"*.intra.example.com",
    },
    "tcp://production.corp.example.com:2376": {
      "HTTPProxy" :"http://proxy.example.com:3128",
      "HTTPSProxy" :"https://user:password@proxy.example.com:3129",
      "FTPProxy" :"http://ftpproxy.example.com:21",
    }
  }
}

Now that we have contexts, there's two separate locations to maintain configuration for environments;

• define a context for the development.corp.example.com and production.corp.example.com connections
• define which proxies to use for each in the ~/.docker/config.json

Proposal

Extend the context spec to support proxy-configurations per context. This will not only solve the issue mentioned above, but also allows (e.g.) and administrator to provide a .context file, containing the correct proxy-configuration that a user should use.

Note perhaps there are other configurations to consider in future (perhaps default labels to apply to containers, or even default memory or cpu constraints). When designing this feature (where to put it in the context), I think it would be good to take future expansion into account (e.g. a defaults section under which more container-configurations can be added, but also if those defaults apply to containers, services (or both)

We should also consider what to do with the existing configuration in ~/.docker/config.json; we can deprecate the "per host" setting (still support it, but add a note that docker context is the future direction if we feel that's the case)

Start by reading the Docker CLI proxy configuration described in docker/cli#93, then inspect how contexts and ~/.docker/config.json are currently represented. The proposal needs an agreed context specification, treatment of existing per-host settings, and a defined scope for container or service defaults before implementation can be considered done.