Subpackage version imports repo client_golang which imports this repo…

This does not cause an import cycle while compiling, so no one’s builds have broken, and go does a decent job at caching the go.mod downloads, so no one has really noticed the stress yet. But just importing the most recent version of client_golang (v1.4.1) ends up cascading through three different versions of client_golang and two versions of common.

https://github.com/prometheus/client_golang/blob/v1.4.1/go.mod#L11 depends on common v0.9.1
https://github.com/prometheus/common/blob/v0.9.1/go.mod#L13 depends on client_golang v1.0.0
https://github.com/prometheus/client_golang/blob/v1.0.0/go.mod#L10 depends on common v0.4.1
https://github.com/prometheus/common/blob/v0.4.1/go.mod#L17 depends on client_golang v0.9.1
https://github.com/prometheus/client_golang/blob/v0.9.1 has no go.mod so this is the end of the line.

As interdependent versions progress, this cyclic dependency is likely to only grow longer and longer, potentially exponentially exploding the results of go mod graph in turn. It might be a good idea to consider how to deal with it now, rather than later.

Start with the linked go.mod files for client_golang v1.4.1 and v1.0.0 and common v0.9.1 and v0.4.1, then inspect the dependency graph with go mod graph. Trace the version chain described in the issue and determine what change would prevent the cycle from growing. Done means the dependency relationship and its intended resolution are established without breaking builds.