Go: Investigate ways of vendoring the protobuf dependency

[beorn7]

Protobufs are used a lot, unfortunately sometimes in different versions. What happens if a Go program imports github.com/golang/protobuf/proto but also uses client_golang for instrumentation, which might depend on a different version of github.com/golang/protobuf/proto? Even if this kind of conflict might be rare, some users are put off by the mere possibility.

We have already tried to vendor prometheus/client_model completely within prometheus/client_golang via import rewriting. That failed badly because any code using prometheus/client_model directly
suddenly considered the types exported by prometheus/client_model different from those used in prometheus/client_golang. We could, however, vendor github.com/golang/protobuf/proto via import rewriting within prometheus/client_model. All the Prometheus protomessages would be incompatible with other protomessages, but that should not be an issue. It would bloat the resulting code somewhat, though. github.com/golang/protobuf/proto has ~10k LOC.

Pros and cons have to be weighed carefully. Also, solutions for dependency management as they are established within the Go community should be taken into account to not pick contradicting approaches.

@brian-brazil @peterbourgon @juliusv @fabxc

[beorn7]

With the GO15VENDOREXPERIMENT, which is now the default, vendoring intra-library is in principle possible and well understood.

So far, nobody really complained about the protobuf dependency. But we have a plan in place, should that ever happen... Closing this until then.