Rename auth config APIs

[ArthurSens]

This PR builds on #1296; it just renames the Config API to AuthConfig since it only covers Auth.

The reason I'm making this change is that I want Config to be a broader struct. Config should hold all the configuration options that we currently implement as CLI flags. The postgres_exporter will continue to implement this new Config struct using CLI/Env vars, but it will also allow downstream projects to implement the same struct using other strategies, such as Go Tags, YAML deserializers, or any other approach that might be needed.

[sysadmind]

@ArthurSens can you elaborate on what this helps with? The way that I see it, this config struct is already general. The auth modules are just a key in that struct. Do you have larger plans that this supports? I want to understand the context to help figure out the direction.

[ArthurSens]

@ArthurSens can you elaborate on what this helps with? The way that I see it, this config struct is already general. The auth modules are just a key in that struct. Do you have larger plans that this supports? I want to understand the context to help figure out the direction.

Sure thing! I've opened #1299, hoping it makes the goal here easier to understand. This PR (1297) is only about renaming the existing Config to AuthConfig, leaving room for another component to take over the Config struct. I've also renamed the files from config.go to auth.go.

In #1299, I'm reintroducing the Config struct, which holds ALL the things a user can configure that were previously mostly handled through CLI flags. The postgres_exporter still works as a CLI flag, so the new Config struct can be populated as always by parsing kingpin flags, but other downstream projects, like the collector, can choose to build this Struct from other means, e.g., YAML parsing.

I'm 100% open to feedback here. I know that renaming public structs is a breaking change if someone else is already using them. Please let me know if you have something different in mind :)

[sysadmind]

@ArthurSens Thanks for that follow up PR. I think I understand where you're heading now. I'm not sure we need the rename. In my opinion, this struct is already able to hold all of those configuration options. Long term, it would be good for the auth modules to be able to be used more widely in this exporter (I think they're mostly used in the multi-target functionality today). Do you have a specific case in mind where we need this to be separate from the more global config?

[ArthurSens]

Do you have a specific case in mind where we need this to be separate from the more global config?

Not really, to be honest, I'm just trying my best to keep PRs as small as possible so it's easier to review.

I can adjust #1299 so AuthConfig doesn't exist and we just include AuthModules as part of this new global Config. Would you prefer that these changes be made in #1299 as well? It feels like it's big enough already

[sysadmind]

I think that's the better path. I'm confused on your most recent statement though. #1299 is to merge other changes into this PR branch right? I think this PR (#1297) gets closed and #1299 just rebases on master right?

[ArthurSens]

I think that's the better path. I'm confused on your most recent statement though. #1299 is to merge other changes into this PR branch right? I think this PR (#1297) gets closed and #1299 just rebases on master right?

Yeah, if I change the base branch from #1299 to master, then the diff from this PR will show up on that PR as well.

[ArthurSens]

closing in favor of #1330