Properly create telemetry factory when initializing the lambda collector

[johnbley]

Per open-telemetry/opentelemetry-collector#14003 otelcol.Factories.Telemetry is now a required field. I noticed this because our (Splunk/Cisco's) CI test was failing because the lambda collector failed to start, with the error message

    "error": "failed to get config: cannot unmarshal the configuration: otelcol.Factories.Telemetry must not be nil. For example, you can use otelconftelemetry.NewFactory to build a telemetry factory"

This adds the necessary telemetry factory to both places it should be initialized, and additionally drops the now-defunct telemetry:metrics:address section of the configuration yml, because that was also causing a failure-to-start. In my local test the extension now properly starts.

[atoulme]

Maybe consider adding a test running the collector?

[johnbley]

Maybe consider adding a test running the collector?

I'd love to! In a previous discussion it turned up that we (otel) don't currently have any organizational ability to deploy to a test lambda container in CI (billing, auth, etc. etc.). I've asked around internally (Splunk/Cisco) about that but it's always been a low priority to tackle. So I kinda of have to use Splunk CI to test things. 😞

We could fake out the registration server (I have a codex-generated stub for that) to test locally and it would have caught this but wouldn't be as good as a proper deployment to a real lambda environment.

[atoulme]

re adding a test, looks like a pendant to issue #2079

[johnbley]

In case it needs to be called out more explicitly, this bug is preventing the lambda collector from starting, which prevents lambda functions which use the collector from starting, which breaks applications, which is a really bad outcome for an instrumentation system.

[wpessers]

Thank you for the fix @johnbley