Rather than redeploy every formation, only deploy formations that have had their values changed from the defaults.
This still doesn't handle the case where we touch existing processes when scaling _up_, but should decrease the number of services touched otherwise during scaling.
Also note that there are no tests for this new behavior yet (tests incoming).
Refs #7396
This changes restarts to drop the 'release' part that currently gets triggered, which also helps reduce the possibility that a new image layer will be added due to predeploy deploy triggers.
Note that the old method essentially halfway-rebuilt the app (which was what added the extra layer). This refactor removes that, which is a bc-break.
Additionally, scaling processes will result in deploying _only_ restarting the processes being scaled.
Closes#2184
The Procfile is now extracted in the pre-deploy step for every deploy and otherwise not removed. Thus, it should always exist when necessary - web will be scale to 1 automatically and it won't need to be present on future ps:scale calls since we'll have the scale file - and the command can execute faster.
Not all properties can be set globally, and the "appName" in the global case is currently defaulted to `--global`. This is okay because domain label names cannot start with hyphens, and all app names must be valid domain label names.
Moving verification of input to the earliest place is the best way to decrease the need to validate this further downstream.
Additionally, some of the existing checks were.... lacking :)
Rather than attempting to always extract the Procfile, reference the one that was extracted by the last deploy. This fixes issues where 'docker container cp' may fail intermittently for lord knows what reason.
Closes#4083
There are other places in the codebase that currently act on all apps or could benefit from being able to do so. Being able to run `common.RunCommandAgainstAllApps()` and get that for free will be a boon to implementing this functionality elsewhere.
