Stack deployments should not override current service scale

When re-deploying an existing stack in order to update services inside it (with docker stack deploy), the stack file's service.deploy.replicas value overrides the current scale of each service. For example, if I have a stack called my-stack with

services:
  my-service:
    deploy:
      replicas: 3

but because of increased load, at some point I scaled the service up to 9 replicas using:

docker service scale my-stack_my-service=9

then running the following command to, e.g., get new images will reduce the scale back to 3:

docker stack deploy -c my-stack.yml my-stack

The service.deploy.replicas key, in a stack/compose file, is unique because it represents a starting condition for a service in a swarm cluster rather than a desired condition. A major reason for deploying services or stacks to a swarm cluster is to be able to trivially scale them up or down in response to changing conditions, load, # users, etc., so running docker service scale is valid even with stack deployments.

Because it's a starting condition, docker stack deploy should not alter the current scale (or # replicas) of any services within the stack when re-deploying. It can easily regress a swarm cluster to not handling the current load (causing downtime and requiring manual re-scaling every time) and it can be destructive for services that are deployed with replicas: 0 because of some manual step in their deployment.

Start at the docker stack deploy entry point and compare its handling of service.deploy.replicas with docker service scale. Verify that redeploying an existing stack preserves the current replica count, including a service scaled above its file value and one set to 0.