Validate config before writing .yaml or starting project, resolves #1095

[andrewfrench]

The Problem/Issue/Bug:

Only certain config values were being validated before attempting to start a project, which could lead to cryptic errors. When supplying config value flags to ddev config, no validation was done before writing the config file.

How this PR Solves The Problem:

These changes do more to ensure that configuration values are valid before either 1) writing a config file, or 2) attempting to start a project. Additionally, many string values in the source code were constantized and a few helper functions were added as a requirement for valid value lookup.

Similarly, instead of inspecting error values, a small set of error types has been added allowing for error type comparisons, decoupling the error from its text value.

Manual Testing Instructions:

Using the CLI's config flags, ensure that invalid choices lead to validation errors:

• --projectname invalid!name
• --php-version 1.9
• --projecttype typo4
• --webserver-type nginx-cgi
• --additional-hostnames valid,in_valid
• --additional-fqdns valid.com,in_valid.com

Provide combinations of these invalid values alongside valid values to ensure ddev rejects invalid values and, when appropriate, outputs the valid values for that flag.

Using config.yaml, ensure that invalid values lead to validation errors after saving the file and when attempting to ddev start the project:

• name: "invalid name"
• type: drupal10
• php-version: 9.9
• webserver-type: nginx-cgi
• additional-hostnames: [valid, in_valid]
• additional-fqdns: [valid.com, in_valid.com]
• provider: unknown

Automated Testing Overview:

Constantization updates will largely rely on the build process completing successfully, ensuring all new
symbols are resolved correctly.

Test cases have been added to ensure invalid config values generated appropriate errors.

Related Issue Link(s):

#1095

Release/Deployment notes:

[rfay]

This is awesome in so many different ways, wow.

• Long-deferred need to use typed errors
• validation within the code
• Validation in config flags
• Validation in config.yaml

Way, way more ambitious than I was expecting, and so much better.

There's one switch that could be more compact, and maybe we can talk about inverting the logic in that very fragile code. But definitely approved.

$ ddev config --php-version=9.2
You are reconfiguring the project at /Users/rfay/workspace/d8git.
The existing configuration will be updated and replaced.
Found a drupal8 codebase at /Users/rfay/workspace/d8git
failed to validate config: invalid PHP version: 9.2, must be one of [5.6 7.0 7.1 7.2]
rfay@rfay-mbp-2017:~/workspace/d8git$ vi .ddev/config.yaml
rfay@rfay-mbp-2017:~/workspace/d8git$ ddev start
Unable to get project(s): invalid PHP version: 9.2, must be one of [7.1 7.2 5.6 7.0]
rfay@rfay-mbp-2017:~/workspace/d8git$ vi .ddev/config.yaml
rfay@rfay-mbp-2017:~/workspace/d8git$ ddev config --webserver-type=nothing
You are reconfiguring the project at /Users/rfay/workspace/d8git.
The existing configuration will be updated and replaced.
Found a drupal8 codebase at /Users/rfay/workspace/d8git
failed to validate config: invalid webserver type: nothing, must be one of [apache-fpm apache-cgi nginx-fpm]

[rfay]

I love typing errors. That's going to be a big step forward for us. Thanks!

[rfay]

This is a massive improvement, great with the error typing.

It will read a lot better with case webContainerExists, invalidHostname, invalidAppType, ... : return app, err

This is absolutely suspect code though, quite fragile, and as you'd expect it has a lot of history. I'd rather we had the types of error we're going to ignore here instead of the types we're going to return. That would be less fragile. We could do that either this time or next time.

[rfay]

You coming over to the dark side of maps?