rpk commands with -v should return some profile info

[supahcraig]

Who is this for and what problem do they have today?

I created a new self-hosted cluster but when I ran rpk commands it said it was unable to reach an address which was clearly a BYOC seed broker address. rpk profile print confirmed I was using the profile I thought I was using, but it turns out I had forgotten about some environment variables from a prior BYOC cluster I had created. The probem is that there is no way to know how rpk is sourcing things like broker lists, sasl users, etc. If you didn't remember you had set an environment variable you would literally never resolve this.

It would be helpful for the -v option on rpk commands to return the source of the information used to execute the command.

What are the success criteria?

I don't intend to be prescriptive about what the output needs to look like, but something like this is what I have in my head.

cnelson 23:56:50 ~/sandbox/deployment-automation % rpk cluster info -v
08:47:04.632  DEBUG  using broker address found in environment variable REDPANDA_BROKERS
08:47:04.632  DEBUG  using SASL config found in environment variable REDPANDA_SASL_USERNAME
.
.
.

or if a profile was in use

cnelson 23:56:50 ~/sandbox/deployment-automation % rpk cluster info -v
08:47:04.632  DEBUG  using broker address found in rpk profile <profile name>
08:47:04.632  DEBUG  using SASL config found in rpk profile <profile name>
.
.
.

Or if you had a local redpanda.yaml:

cnelson 23:56:50 ~/sandbox/deployment-automation % rpk cluster info -v
08:47:04.632  DEBUG  using broker address found in <path to local redpanda.yaml>
08:47:04.632  DEBUG  using SASL config found in <path to local redpanda.yaml>
.
.
.

Why is solving this problem impactful?

In the cloud UI we invite users to create environment variables to help them connect to their cluster, but rpk profiles is ultimately a better option and if they have multiple clusters it's essentially required. It is very easy to forget that you've got env vars set, and can easily point to the wrong endpoints or just plain not work as in my case. Adding this sort of output to the verbose option will make troubleshooting this sort of thing much easier.

JIRA Link: CORE-1856