concord-cli: support for remote secrets, configurable secrets providers

[ibodrov]

Config example:

# ~/.concord/cli.yaml
contexts:
  default: # those are the defaults, we don't need to put them in the local config file
    secrets:
      vault:
        dir: "${configDir}/vaults"
        id: "default"
      local:
        enabled: true
        writable: true
        dir: "${configDir}/secrets"
      remote:
        enabled: false
        writable: false
        confirmAccess: true
  prod: # alternative "context", activated with "concord-cli run --context prod ..."
    secrets:
      local:
        enabled: false        
      remote:
        enabled: true
        baseUrl: "http://concord.prod.acme.com"
        apiKey: "foobar"

In future, the feature can be extended to support multiple providers of the same type.

[benbroadaway]

I'm a littttle bit concerned this opens a door to a big potential oopsie. One should be very considerate of their handling of secrets from "real" environments to start with, but this could easily end up with a "I got out of a pickle with the CLI pointed at prod real quick on Monday and forgot to turn off remote secrets...Tuesday got interesting 😬"

That could be addressed with an extra setting for the remote config(s), or any config since the same situation is possible--just fewer hoops to jump through (e.g. creating specific secrets locally for secrets.local vs secrets.remote unlocking any available secret in the system). Something like secrets.remote.warnOnAccess: true that gives a prompt/warning that it's about to access a remote secret.

[ibodrov]

That is a valid point. I will see if we can add a prompt there.
Or maybe providers should be configured for specific "contexts" and the CLI can require something like `--context prod" to use a non-default context?

[ibodrov]

@benbroadaway how about now -- see the example in the PR description.
Users will need to explicitly say concord run --context myNonDefaultContext.

[ibodrov]

Added the confirmation prompt as well