[chore]: bump prometheus common dep to support RFC7523 3.1

[JorTurFer]

Description

Prometheus common pkg supports JWT Profile for Oauth (RFC7523 3.1) since latest version (v0.67.3). This PR bumps the dependency and also update the custom yaml parser to handle that now there are more than 1 commonconfig.Secret and one or more it can be empty.

Testing

I've tested this using the kong integration test, just updating the file with the values required to invoke the new code from prometheus common pkg and checked that I can get a valid token from the oauth server that requires this grant-type

I don't know if this requires some extra test (maybe some unit/integration) as this really comes as feature of prometheus dep and it's already tested there

[github-actions]

Welcome, contributor! Thank you for your contribution to opentelemetry-collector-contrib.

Important reminders:

• Please review our Contributing Guidelines.
• Don't forget to sign the Contributor License Agreement (CLA) if you haven't already.

A maintainer will review your pull request soon. Thank you for helping make OpenTelemetry better!

[JorTurFer]

Tomorrow I'll check the unit tests to solve them. I think that after latest changes testing I have broken them

[JorTurFer]

Could you trigger again tests please? I've found the issue and I've fixed it. Current config.Secret values can be empty but the marshaler required them. When it tried to unmashal the value for client_secret, it was perfectly able before the dep upgrade because oauth2.client_secret was the only secret inside that section, as now there is another secret, we have to allow empty values or the process fails.

Instead of allowing *config.Secret (my first option) as custom marshaler config, we just need to omit empty values (changing the custom marshaller breaks the "magic" to not corrupt the value with <secret>)

[JorTurFer]

I've found that there is a problem with the omit empty for common.Secret types, I'm working on it and I'll mark PR ready for review again when it's ready

[JorTurFer]

This automated PR updated the pkg to 0.67.3 which technically adds the support, but the version 0.67.3 didn't work for otel collector because a marshal problem that happened with common.Secret type.
common v0.67.4 solves the problem and I have added a test to verify the marshal to ensure that it works, PTAL

Does it make sense to create a changelog record to notify that this support has been added as as enhancement? This comes just from bumping deps but maybe it's relevant for someone

[ArthurSens]

Thanks! I wouldn't call this "chore" though, since it adds a feature. Could you add a changelog entry?

[JorTurFer]

Thanks! I wouldn't call this "chore" though, since it adds a feature. Could you add a changelog entry?

Sure, I'm going to review the CI and add the changelog. Thanks!

[JorTurFer]

I get errors about pending go mod tidy in multiple places that I've not touched. I guess that it's because there is something ensuring the same version in all the components. Is it expected that I update all at once?

Reading https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/CONTRIBUTING.md I have it clear now, sorry because I should have read it before :(

[JorTurFer]

@ArthurSens could you trigger again the CI?

[JorTurFer]

lol, when I've consolidated dependencies make gotidyit has added so many people as reviewers, sorry 😢

[ArthurSens]

LGTM!

No worries about pinging several people, the codebase of this repository is organized like this and bumping a widely used dependency will always ping this many people 😅

[otelbot]

Thank you for your contribution @JorTurFer! 🎉 We would like to hear from you about your experience contributing to OpenTelemetry by taking a few minutes to fill out this survey. If you are getting started contributing, you can also join the CNCF Slack channel #opentelemetry-new-contributors to ask for guidance and get help.