[extension] Add ModuleInfo to extension.Settings

[dpaasman00]

Description

Paired with @djaglowski on adding a new struct, ModuleInfo, to extension.Settings. The goal is to make the collector's component go modules available to extensions that may want to use that information (in particular the OpAMP extension).

We didn't want to modify the extension package but adding this information to the Settings struct seems to be the most painless way to make this information available. No function signatures need to be updated and existing extensions can just ignore the new field on the Settings struct unless they want the information.

Link to tracking issue

Fixes #10876

Testing

Updated existing tests.

[djaglowski]

Are there any test cases we can add? If nothing else maybe a test that demonstrates how it would be used in extension creation?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.62%. Comparing base (caae756) to head (6432d9e).
Report is 18 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #10888      +/-   ##
==========================================
+ Coverage   91.60%   91.62%   +0.01%     
==========================================
  Files         404      404              
  Lines       18980    18990      +10     
==========================================
+ Hits        17387    17399      +12     
+ Misses       1234     1233       -1     
+ Partials      359      358       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[djaglowski]

LGTM, but I'll recuse myself from approval since I contributed to it.

[djaglowski]

cc: @open-telemetry/collector-maintainers

[mx-psi]

Should this have more structure? For example, should we use https://pkg.go.dev/golang.org/x/mod@v0.20.0/module#Version (or something similar) instead?

I am a bit hesitant about using module.Version directly since that module has a 0.x version, but something similar may make sense

[djaglowski]

I'm not opposed to structuring it more but it wasn't clear to me either what that structure should be. I think it's worth noting that the module string is something of a standard in its own right, since its interpretable by go tooling.

[mx-psi]

I'm not opposed to structuring it more but it wasn't clear to me either what that structure should be

Hm, I guess a light wrapper around the module.Version I linked above makes sense.

But thinking about it more I remembered open-telemetry/opentelemetry-collector-contrib/issues/31136, where we put int as the type for a stepping number, that is commonly represented as a string, and then found out that there are edge cases where it's not representable as an int.

I guess a wrapper would make this situation manageable, but the lesson I learned there is that using a string may be better when you don't control the evolution of what you are representing.

This is all to say: if you feel like a string works, let's go with a string :)