Follow-up improvements for docker stack --detach options

[thaJeztah]

Follow-ups to;

• Add support for --detach flag in stack deploy #4258
• Add support for --detach flag in stack rm #4259
• related: Support --detach flag in docker stack deploy / rm #373

The current implementations are functional, but could use some improvements to provide a better / more consistent UX.

A couple of things happening when trying this PR;

• waitOnServices is waiting for services sequentially. This means that it only reports progress of the service it's currently waiting for, but won't report progress for other services that are being deployed.
• ^^ likely due to the internal use of maps, the order in which services get deployed is randomised. This wasn't very apparent when "detached", but now becomes more visible.
• ^^ it also becomes more apparent that the existing progress bars / progress output was clearly designed to be used for a single service. With multiple services being deployed, the progress-bars become a bit confusing;
  • There's separate output for "creating", "progress", "converging" output
  • Progress-bar and "converging" steps don't include the name of the service (so it's hard to see what service is shown) but may include service ID

Perhaps it's not a strict blocker for this PR, but it does all feel a bit "unfinished".

Perhaps we can't fix all the progress output (some of that may also be related to the daemon response - haven't checked that), but we could consider

• Flipping the implementation, and make WaitOnService accept multiple services. When used for docker service create, we would only pass a single one, but when used for docker stack deploy, it would pass multiple services.
• When called with multiple services, can we make those print progress in parallel? (I guess there may be some complication there, because of the multiple outputs per service, so perhaps that would still be a for a follow-up)
• This doesn't look like anything "new", but wondering if we can sort the order in which services are deployed (if we can't preserve order from the compose-file, we could sort alphabetically) at least so that there's a consistent order in which services are deployed.

Here's what I tried with this PR;

A compose file with 3 services. One of which had a health-check that takes some time to become healthy;

services:
  a_service:
    image: nginx:alpine
    healthcheck:
      test: ["CMD", "sh", "-c", "if [ ! -f \"/count\" ] ; then ctr=0; else ctr=`cat /count`; fi; ctr=`expr $${ctr} + 1`; echo \"$${ctr}\" > /count; if [ \"$$ctr\" -gt 4 ] ; then exit 0; else exit 1; fi"]
      interval: 10s
      timeout: 3s
      retries: 3
      start_period: 60s
    deploy:
      replicas: 3
  b_service:
    image: nginx:alpine
  c_service:
    image: nginx:alpine

When deploying the service, the order was randomized; the first service ("service_c") deployed immediately, but then was checked for 5 seconds to verify if it was "stable". After this, the second service was waited for ("service_a"). This service has the health-check so it now had to wait for a minute or so to become healthy;

time docker stack deploy -c ./docker-compose.yaml --detach=false mystack
Creating network mystack_default
Creating service mystack_c_service
Creating service mystack_a_service
Creating service mystack_b_service
overall progress: 3 out of 3 tasks
1/3: running   [==================================================>]
2/3: running   [==================================================>]
3/3: running   [==================================================>]
verify: Service oj3m4chiob0af8t9qrt320gmj converged
overall progress: 0 out of 3 tasks
1/3: starting  [============================================>      ]
2/3: starting  [============================================>      ]
3/3: starting  [============================================>      ]

After that, it continued with the next service ("service_b") which (in the meantime) already was deployed successfully, but due to the client-side logic to verify if it's stable, it still waits for 5 seconds to verify that;

,,,
verify: Service z9xhes4ie4maux02hwskinv2i converged
overall progress: 3 out of 3 tasks
1/3: running   [==================================================>]
2/3: running   [==================================================>]
3/3: running   [==================================================>]
verify: Service nbzvce7qc0vh7shn9rpdkaxdd converged

________________________________________________________
Executed in   64.18 secs      fish           external
   usr time  440.30 millis    0.18 millis  440.12 millis
   sys time  182.75 millis    1.22 millis  181.53 millis

Originally posted by @thaJeztah in #4258 (comment)