Enable users to configure persistent default flag values for the apps plugin

[heyjcollins]

Description of problem

Developers will provide the same flags/values repeatedly when iterating on their application code.
Typing or copy/pasting those same flag values for every workload create/update/apply adds friction to the developer workflow.
We should make it possible for the user to configure/persist sane defaults for a subset of the supported flags such that they can execute their commands without having to provide the same flag/values repeatedly.

Proposed solution

• Support setting and unsetting config values for specific flags supported in workload create/update/apply commands.
• Where a configured value for a given flag exists, use the value.
• Where no flag or config value is provided for a required flag, throw an error
• Where flag/value has been provided AND a config value exists, the flag value takes precedence
• this command doesn't accept any positional args or flags/values - it's interactive (based on the cobra library)

Flags targeted for configuration (configurable flags should be listed in alphabetical order in the UI)

1. caCertsPath
2. debug
3. file
4. live-update
5. local-path
6. password
7. source-image
8. sub-path
9. token
10. username

Command and Interactions:

Listing / checking config (styling based on the cobra implementation used by tanzu login)

if user starts typing, the options displayed are filtered
user can use up/down arrow keys to move the ">" to their desired selection
hitting triggers edit mode.

$ tanzu apps config
? Select option [Use arrows to move, type to filter]
   caCertsPath     (not set)
> debug            (false)
  file             (not set)
  live-update      (false)
  local-path       (not set)
  password         (not set)
  source-image     (not set)
  sub-path         (not set)
  token            (not set)
  username         (not set)

username
password

Setting key that expects a bool

If user hits from the selected option and the selected option is a boolean, the UI should update as follows:

$ tanzu apps config
? Select option [Use arrows to move, type to filter]
Enable debug by default?
> true
  false   (default)

  --debug=true will be set by default when creating or updating workloads.
  
  This default can be overridden by using a --debug=false flag
  example: "tanzu apps workload update NAME --debug=false" 
$

Setting key that expects a string

Example below assumes user has clicked on "local-path" select option...

$ tanzu apps config
? Select option [Use arrows to move, type to filter]
? Set local-path: <user-entered-value-goes-here>

  --local-path will be set to <user-entered-value-goes-here> by default for any command that accepts the flag
  
   The --local-path flag will take precedence over the default.
   example: "tanzu apps workload update NAME --local-path value" 
$

the --local-path will be set to.... message should be displayed only after the user submits the value
upon submission, the config value is saved, confirmation text and other messaging is displayed and the command exits 0

Configuration UX when values have been previously configured

$ tanzu apps config
? Select option [Use arrows to move, type to filter]
  caCertsPath      (not set)
  debug            (true)
  file             (my-workload.yaml)
  live-update      (false)
> local-path       (.)
  password         (not set)
  source-image     (gcr.io/pivotal-knative/jc-apps)
  namespace        (not set)
  sub-path         (not set)
  token            (not set)
  username         (not set)
...

Unsetting key that expects a string

Example below assumes user has clicked on "local-path" select option...
Upon selection, the entry "area" is blank and if user hits the value will be unset

$ tanzu apps config
? Select option [Use arrows to move, type to filter]
? Set local-path: 

  --local-path value is not set
$

Help Text

$tanzu apps -h

Applications on Kubernetes

Usage:
  tanzu apps [command]

Aliases:
  apps, app

Available Commands:
  cluster-supply-chain   Patterns for building and configuring workloads
  config                 Configuration for the apps CLI plugin
  workload               Workload lifecycle management

Implementation Notes/questions

the config file should be stored at ~/.config/tanzu/apps/config.yaml

Describe alternatives you've considered

1. Set config values via ENVVARS - as per Enable users to specify default flag values for the apps plugin via environment variables #114 (which we will not be implementing)
2. provide flag values via file that are merged together (e.g. tanzu apps workload apply hello-world -f workload.yaml -f overlays.yaml) -- suggested by @scothis

Additional context

Add any other context or screenshots about the feature request here.

[scothis]

A possible "cheap" way to handle this is to allow a user to specify multiple files that are merged together. Something like

tanzu apps workload apply hello-world -f workload.yaml -f overlays.yaml

[danfein]

Consider: Story to add feedback message to crud commands to inform folks when we are using configured defaults. The info may show up in the diff already, I need to check out each of the configurable values to think it thru further.

[danfein]

Consider: story to add hint to local code commands to let folks know they can persist some of the values

[heyjcollins]

We've decided against implementing this feature until/unless there's demonstrable interest in it from the community.