proposal: Move unrelated code to separate modules.

[bwplotka]

Proposal

To reduce the damage radius of release (e.g. compatibility issues), increase dev velocity and reduce indirect/direct dependencies for downstream users, we could consider splitting client_golang into multiple modules.

Specifically I would move to new modules:

• All collectors https://github.com/prometheus/client_golang/tree/main/prometheus/collectors (or each collector to its own?)
• testutil, for https://github.com/prometheus/client_golang/issues/1639 needs.
• http Prometheus client, where we could experiment with OpenAPI spec generated code as well.

We could split more, but other stuff tended to be less problematic in past and moving slower, or not have new deps.

Risks

Personally, the main pain-point of using multi-module SDKs (e.g. otel-go) were:

• Discovery of modules. When you need a piece of code to have e.g. processor/collector working, if it's part of a single Go module, IDE auto-completion will help you a lot figuring the required type or method. This does not work across modules, and it's really painful to manually walk through docs or examples to figure this out. Counter argument: In this proposal we do have less "connections" between modules (only one core module?), plus proposed module split has different functional purpose?
• Discovery of releases and dependencies across them. It's sometimes frustrating to have 10 new go.mod deps for core functionality. It's even more frustrating if some update of e.g. collectors/processors module require anyway update of core module (little point in separate module?). Counter argument: In our case I don't think we want to change main core module out of v1 or significantly, so perhaps that connection will be more rare?
• Releasing tooling is painful? You need to create those weird releases with prefixes, but maybe community already got used to this?

Would be curious of @dashpole opinion if he would advise this (: