[service] Share log sampler core allocations with reflect magic

[jade-guiton-dd]

Context

PR #12617, which implemented the injection of component-identifying attributes into the zap.Logger provided to components, introduced significant additional memory use when the Collector's pipelines contain many components (#13014). This was because we would call zapcore.NewSamplerWithOptions to wrap the specialized logger core of each Collector component, which allocates half a megabyte's worth of sampling counters.

This problem was mitigated in #13015 by moving the sampling layer to a different location in the logger core hierarchy. This meant that Collector users that do not export their logs through OTLP and only use stdout-based logs no longer saw the memory increase.

Description

This PR aims to provide a better solution to this issue, by using the reflect library to clone zap's sampler core and set a new inner core, while reusing the counter allocation.

(This may also be "more correct" from a sampling point of view, ie. we only have one global instance of the counters instead of one for console logs and one for each component's OTLP-exported logs, but I'm not sure if anyone noticed the difference anyway).

Link to tracking issue

Fixes #13014

Testing

A new test was added which checks that the log counters are shared between two sampler cores with different attributes.

[codecov]

Codecov Report

Attention: Patch coverage is 80.85106% with 9 lines in your changes missing coverage. Please review.

Project coverage is 91.28%. Comparing base (8cd0191) to head (d6d45d7).
Report is 36 commits behind head on main.

Files with missing lines	Patch %	Lines
...nternal/telemetry/componentattribute/logger_zap.go	79.06%	6 Missing and 3 partials ⚠️

❌ Your patch status has failed because the patch coverage (80.85%) is below the target coverage (95.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #13107      +/-   ##
==========================================
- Coverage   91.48%   91.28%   -0.21%     
==========================================
  Files         506      511       +5     
  Lines       28555    28802     +247     
==========================================
+ Hits        26123    26291     +168     
- Misses       1917     1994      +77     
- Partials      515      517       +2     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mx-psi]

My comment from today's 1.0 meeting: I think we want to avoid the following situations:

1. Somebody uses an incompatible zap version and the error message they get regarding this is too cryptic. Ideally the message links to somewhere where they can complain and say "hey, you broke me".
2. We upgrade zap, this solution stops working but we don't realize

[jade-guiton-dd]

@mx-psi

1. I added a panic message when our assumptions on the sampler type fail with a link to this PR, hopefully that should work.
2. I can't think of a way that Zap could make this stop working without either a panic on startup (eg. the Core field no longer exists) or the test failing (eg. they inline the counters inside the struct, so no more sharing).

[jmacd]

Thanks for the detailed comment.

[bogdandrutu]

@jade-guiton-dd would be good if we can file an issue for this on their side and link it here.

[jade-guiton-dd]

I filed an issue a while back, added it to the comment.