support/config: allow multiple flags to be defined with the same name across commands

[leighmcculloch]

PR Checklist

PR Structure

• This PR has reasonably narrow scope (if not, break it down into smaller PRs).
• This PR avoids mixing refactoring changes with feature changes (split into two PRs
  otherwise).
• This PR's title starts with name of package that is most changed in the PR, ex.
  services/friendbot, or all or doc if the changes are broad or impact many
  packages.

Thoroughness

• This PR adds tests for the most critical parts of the new functionality or fixes.
• I've updated any docs (developer docs, .md
  files, etc... affected by this change). Take a look in the docs folder for a given service,
  like this one.

Release planning

• I've updated the relevant CHANGELOG (here for Horizon) if
  needed with deprecations, added features, breaking changes, and DB schema changes.
• I've decided if this PR requires a new major/minor version according to
  semver, or if it's mainly a patch change. The PR is targeted at the next
  release branch if it's not a patch change.

What

Allow multiple flags to be defined with the same name that are attached to different commands.

Why

Cobra allows the definition of flags on different commands that have the same name. There can be good reasons to do this like two subcommands requiring the same parameter, but other commands not requiring that parameter.

Viper also supports this too, if we bind flags into viper as they're required, but not if we bind them all upfront.

This comment spf13/viper#233 (comment) suggests binding flags to wiper when a command is actually running. This has other advantages, like there are not parameters for other commands bound unnecessarily.

Fix #2421

Known limitations

Our command line usage is somewhat untested. I don't think we have extensive tests of Horizon's command line interface like we do for what we could define as the most critical components of Horizon. There's some risk in our ability to identify issues with any change to this area of code because of that. I've attempted to address the risk by adding some general tests to the support/config package.

[leighmcculloch]

This breaks horizon because it assumes flags are bound outside of commands I think. I'll need to look more into this.

[leighmcculloch]

I think 38a453b resolves the issues for Horizon. My issue was that I wasn't ensuring bind would occur in the require case.

[leighmcculloch]

In d48c92d I've made a small change to Horizon to require the --db-url param in the migration commands, because it wasn't being required before and it looks sort of accidental that the param worked before. A side-effect of that commit is that if the db-url flag is empty now the migration command will fail in the same way it does for the root/serve command.

[ire-and-curses]

I don't see a reason to prefer how we were doing this before. In the interests of expediency I'm approving this, but we should do some deeper options checking next week before releasing this.

[leighmcculloch]

Thanks. I've run the commands that call viper.Get* directly and so I don't expect there to be issues beyond the ones I've addressed in the last couple commits, but there could be and I'll own any issues that are related to this change that show up next during the Horizon testing.