Add --datasource.* CLI flags to replace DATA_SOURCE_* env vars

[nicolastakashi]

Closes #1372. Part of #1371.

Adds CLI flags for the Postgres connection config, which was previously only settable via env vars:

• --datasource.dsn (replaces DATA_SOURCE_NAME)
• --datasource.uri (replaces DATA_SOURCE_URI) / --datasource.uri-file (replaces DATA_SOURCE_URI_FILE)
• --datasource.user (replaces DATA_SOURCE_USER) / --datasource.user-file (replaces DATA_SOURCE_USER_FILE)
• --datasource.pass (replaces DATA_SOURCE_PASS) / --datasource.pass-file (replaces DATA_SOURCE_PASS_FILE)

GetDataSources() now takes a DataSourceOpts struct. Each field falls back to its existing env var when unset, so behavior is unchanged when only env vars are set. Precedence is unchanged: dsn wins over everything, *_FILE wins over the plain value, whether set by flag or env var.

Env vars still work as-is here. Deprecation warnings (#1373) and doc updates (#1374) are separate.

[sysadmind]

Okay this one I'm less sure about. Specifically anywhere that we take in values that can be considered secret, I am against using a CLI flag. It is too easy to expose those values when they are passed via flag.

[nicolastakashi]

Okay this one I'm less sure about. Specifically anywhere that we take in values that can be considered secret, I am against using a CLI flag. It is too easy to expose those values when they are passed via flag.

I agree 100%, I was thinking about introduce a --datasource.config-file that people could use one or another and config files could be mounted from secrets, wdyt @sysadmind ?

[ArthurSens]

Agree that a config file is safer than CLI flags for sensitive information! I'm just not sure if we should create yet another configuration file or if we should extend the existing auth-modules file 🤔

[sysadmind]

I think we should combine with auth modules if we're looking at a file for config. That said, I think we should keep env vars for secrets. Like you might choose to pass DATASOURCE_PASSWORD or something similar for the password to connect. That makes something like passing it to a pod in Kubernetes from a secret easy. Kubernetes is another great reason not to have sensitive values in cli flags because it's so easily readable in the API.

[ArthurSens]

I'm not a fan of env vars, it also breaks the embedded use case. One single binary running several instances of Postgres exporters cannot set multiple env vars for each secret. I'd rather keep everything on files 😬

[sysadmind]

It only breaks embedding if that's in the part of the library that's embedded. That's what the cmd/ or main package is for. It hooks up things for THIS cli binary.

[ArthurSens]

good point!

[nicolastakashi]

I personally would avoid two ways of configuring secrets, but I think we need to be all or nothing.

So I'm fine on keeping those two options as env vars and expanding the auth modules later.

I'll patch the PR with that change