[extension/googleclientauth] Add GCP auth extension implementation

[damemi]

Description:
Follow up to boilerplate PR #31518
This adds the functions calls to actually implement the extension using our downstream libraries.

It also enables the shutdown tests for this extension (lifecycle tests do not seem possible for us currently)

Link to tracking Issue: n/a

Testing: downstream unit and integration tests, shutdown tests here

Documentation: Here and downstream READMEs

[dashpole]

Actually, can you add tests for the config? Usually, that involves a testdata directory with example configs. Like this one: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/exporter/googlecloudexporter/config_test.go.

It would also be good to check for leaked goroutines: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/exporter/googlecloudexporter/package_test.go

[damemi]

@dashpole sure, I'll add config tests. We do have the leaked goroutines test already https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/e867aa84edb2dbe0570b57681ba62bdbf92e1d37/extension/googleclientauthextension/package_test.go (is there anything we need to add to that?)

[dashpole]

Nope, nothing else there. I just missed them when I looked

[damemi]

@dashpole I updated to add config tests, but double check my pointer logic in aa8288f

For this extension we return a pointer default config downstream https://github.com/GoogleCloudPlatform/opentelemetry-operations-go/blob/4caace7de8789f91dc3ddcdbcd328db002c44abb/extension/googleclientauthextension/config.go#L58

But for our exporters, it's not a pointer: https://github.com/GoogleCloudPlatform/opentelemetry-operations-go/blob/4caace7de8789f91dc3ddcdbcd328db002c44abb/exporter/collector/config.go#L198

Not sure if this is intentional, but I want to make sure this won't cause a nil pointer in the config. The code is also kind of weird. The alternative is another release downstream to not use a pointer when we call DefaultConfig, then I think the embedded type should just work

[dashpole]

Why did you need to add the pointer?

[damemi]

@dashpole you're right, I could have dereferenced it and think I was misreading the error that I was seeing. I didn't save it, but the issue was with a conflict in the upstream and downstream Config types. I think we should refactor the downstream extension code to not rely on the component.Component interface if possible and just use a downstream struct. That's closer to what our exporters do. But for now this should work

[damemi]

Fixed conflicts, @dashpole this is still ready to merge

[damemi]

@djaglowski hi, since you merged the last PR for this component I wanted to see if this was ready to merge? It's been a couple weeks with the ready-to-merge label set and it's tough to keep up with the merge conflicts that keep popping up. Would like to nudge this if possible, thanks!

[djaglowski]

@damemi, thanks for the ping. Always feel free to ping me or any other maintainer as soon as an approver marks it ready to merge.