Support pg_stat_statements robustly

[wrouesnel]

The proposal in #35 needs some careful analysis before merging.

The most important aspect is that the queries.yaml file we currently include is not included as part of the integration testing because it is not enabled by default.

Most likely we need a whole new testing regime for it and to ensure the file is separated into PG -specific versions.

[tmc]

what are the next steps here? a test matrix for pg versions and version-specific queries.yaml?

[wrouesnel]

Probably the queries.yaml file needs to have the same lock out syntax that's supported internally for versions. At which point I think the built-in metrics would just be an encoded yaml file to keep single binary deployability alive.

[wrouesnel]

Relates to #122

[gsstark]

We have a long list of queries we add to queries.yaml here. This is a dangerous situation since it means we will not be able to easily take new versions of postgres_exporter without dealing with complex naming conflicts between our metrics and the upstream metrics.

I would like to start sending pull requests for adding each of the queries we've written here but I'm not clear how you would like to proceed. Should I convert them to built-in metrics or do you want to use the yaml file?

[wrouesnel]

pg_stat_statements depends on module level support, so it's a problem to just include it by default. I suspect what's needed is some special-casing code which checks for the module and enables the metrics if it's found (and maybe if there's a command line flag?)

[wrouesnel]

So apparently I decided to just include it by default anyway as of 698fdb7