[consumer] Mark module as stable

[mx-psi]

Description

Mark consumer module as stable. This is now possible after #11491, since consumererror is a separate module now.

Link to tracking issue

Fixes #9046

[mx-psi]

cc @open-telemetry/collector-approvers

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.63%. Comparing base (f2e05b5) to head (f3d3d8d).

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #11492   +/-   ##
=======================================
  Coverage   91.63%   91.63%           
=======================================
  Files         442      442           
  Lines       23776    23776           
=======================================
  Hits        21787    21787           
  Misses       1618     1618           
  Partials      371      371           

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

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[bogdandrutu]

I would merge this after the release to not rush it. Are we ok with that?

[mx-psi]

I would merge this after the release to not rush it. Are we ok with that?

Definitely, and regardless of the release let's at least wait for a few days at least in case somebody has an objection

[jade-guiton-dd]

It seems that the current API only permits passing signal-agnostic Options to NewLogs/NewMetrics/NewTraces. How sure are we that we will never need or want to implement consumer options that are specific to one particular signal? (As a hypothetical and possibly impractical example, what if once tracing is integrated to the consumer module (#8804), we want to specify attributes from consumed metrics to be included as part of the trace?)

[mx-psi]

Fromt he 2024-10-28 Collector stability meeting, @bogdandrutu will take a look and see if we should do #11492 (comment)

[codeboten]

Will merge after today's release if no one has objections

[mx-psi]

About #11492 (comment) publicly: we discussed @jade-guiton-dd's comment offline.

The summary is: we can still do this by detecting whether an option is signal specific at construction time and returning an error. Jade's suggestion would still improve the API in that it would move a construction time error into a compile time error, but after trying this out it would be quite complex to implement, so we think we can leave the API as is.

TL;DR: we are good to go :)