apps: Nest dev-config settings under 'dev'

[andrewsomething]

The flagName method that is used when binding flags to viper only supports nesting a setting three levels deep.

doctl/commands/doit.go

Lines 287 to 292 in de1918a

	func flagName(cmd *Command, name string) string {
	if cmd.Parent() != nil {
	return fmt.Sprintf("%s.%s.%s", cmd.Parent().Name(), cmd.Name(), name)
	}
	return fmt.Sprintf("%s.%s", cmd.Name(), name)
	}

This causes issues for some deeply nested commands. This is particularly problematic for the doctl apps dev config set/unset commands which contain --dev-config flag. The resulting setting for it is config.set.dev-config which conflicts with the top level config setting that should be a string.

When Viper is init-ed, there is a race to register the setting. Sometimes, it results in the config file containing:

config:
  set:
    dev-config: ""

Others, it has the appropriate:

config: /home/<user>/.config/doctl/config.yaml

This breaks things in bad ways causing doctl auth init to fail unpredictably.

This PR forces the dev-config setting to be nested more deeply, i.e. dev.config.set.dev-config. I don't entirely love this solution, but a more general one would be a breaking change to the configuration file format For example, the settings for DOKS are like cluster.create.region rather than kubernetes.cluster.create.region. I think we should prioritize getting this specific problem fixed over a broader solution.

Fixes: #1281, #1280

[bentranter]

LGTM!

[nicktate]

good catch and fix on this -- I'm on board with the current solution as a fast fix

[andrewsomething]

Pushed an additional commit to not nest deeper if it is already under dev., e.g. if the app dev build command gets a dev-config flag.

[scotchneat]

LGTM

[Marotenten]

Am waiting for what to do