v2: All for v2: Exemplars, Cleanup, Docs, Lint, Proto upgrades and more

[bwplotka]

Fixes #347
Fixes #343
Fixes #345
Fixes #483
Fixes #422

Most (if not all) changes for v2.0.0!

Let me know if I need to split into commits for easier review.

TODO:

• Finish migration guide
• Finish example README
• Find out how to change main to v2 without breaking v1 users. All tested https://github.com/golang/go/wiki/Modules#faqs--multi-module-repositories . One finding: We will need to have multiple releases for each submodule in providers (will create quick script). We can start with 0.1.0 for some of them too and probably it makes sense to do so. Changing default branch to "v2" once v2.0.0 is out, should be fine.

[bwplotka]

At least one thing still bothers me before v2:

So, interceptors/* have interceptors that sometimes consumes providers. Ironically providers have literally only logging adapters and prometheus interceptor (!). It might feel quite odd. Perhaps moving providers/prometheus to interceptors/prometheus (as a separate module) might make more sense? I don't think we plan to add any other metric middleware so it could be equally interceptors/metrics 🤔 (also avoids package name collision). The only odd thing about this alternative is that "metrics" will be the only interceptor that is a separate module (if we want to NOT pollute go-grpc-middleware with very common prometheus import)... WDYT @johanbrandhorst @devnev ?

EDIT: I think I explained all clearly in README, so I would stick to this. Having separate modules in one directory is quite nice.

[bwplotka]

All done and ready for review.

[johanbrandhorst]

Changing default branch to "v2" once v2.0.0 is out, should be fine.

I would prefer that we make a v1 branch off main and merge v2 into main instead. That's what we did for the gateway.

Do we have dependabot set up? With this module sprawl we'll want something to manage updates.

[bwplotka]

I think I addressed all @johanbrandhorst

[johanbrandhorst]

Thanks a lot for this Bartek 🎉