Add config flags to specify image values, closes #1181

[andrewfrench]

The Problem/Issue/Bug:

#1181: Giving troubleshooting/debugging instructions can be complicated when it involves changing web/db/dba image values because it requires editing .ddev/config.yaml.

How this PR Solves The Problem:

Adds several configuration flags to ddev config that will set the images being used:

• --web-image
• --db-image
• --dba-image

To unset these custom image configurations, the following flags have been added:

• --web-image-default
• --db-image-default
• --dba-image-default

And the following flag has been added to unset all custom image configurations in one go:

• --image-defaults

Some image reference getters have been added to versions.go to standardize things.

Manual Testing Instructions:

Provide custom image names to ddev config:

• ddev config --web-image my-web-image
• ddev config --db-image my-db-image:v1.2.3
• ddev config --dba-image my-dba-image:latest

And combinations of the above. Ensure after each execution that .ddev/config.yaml has been updated to reflect the updated image, then test unsetting image values:

• ddev config --web-image-default
• ddev config --db-image-default
• ddev config --dba-image-default
• ddev config --image-defaults

Automated Testing Overview:

Automated tests have been expanded to test the new flags.

Related Issue Link(s):

#1181

[rfay]

Thanks for this!

One thought - although I do expect --db-image to be the correct technique, it's "dbimage" (and friends) that we use in the config.yaml. Should we use reasonable flags or go for consistency with the config.yaml?

[andrewfrench]

I considered both, and I believe --db-image is the correct choice for readability/usability reasons, and because it matches the standard of the other flags (except --projectname and --projecttype, which I'd argue should probably be deprecated/hidden and replaced with --project-name and --project-type for the same reasons).

Edit: I'll actually just go ahead and do that here, it's a small change.

[rfay]

I read this through and could find nothing objectionable. I tried out a number of the options, and tried out the deprecated options that work fine still.

Thanks so much for taking ownership of this stuff and making it so much better. I do wish we didn't have to just keep adding code, but it seems to be the way of cobra.

ddev config -h is enough to choke any horse now! And I guess I'm ok with that. I always just use ddev config and click through anyway. I imagine most people do. I think making sure that ddev config can do anything one would want to do from the command line is the right thing.