receiver: add PartialReceiveError for partial success metrics

[Ady0333]

Fixes #14440

Description

Receiver observability metrics currently follow an all-or-nothing error model: when a receiver returns any error, all received items are marked as failed or refused. This behavior is inaccurate for receivers that can partially process data (for example, when only some metrics fail translation or validation).

This change introduces a new receiver-specific error type, receivererror.PartialReceiveError, which allows receivers to report the exact number of items that failed during processing. The observability helper detects this error and:

• Records accepted items as total − failed
• Records failed items accurately
• Preserves existing behavior for full failures and downstream errors
• Treats partial success as a successful request for otelcol_receiver_requests

This enables accurate self-observability metrics without breaking existing receivers or dashboards.

Link to tracking issue

Fixes #14440

Testing

Added unit tests for receivererror.PartialReceiveError, including:

Error detection
Failed item extraction
Wrapped error handling

Added tests in receiverhelper/obsreport_test.go to validate:

Correct accepted / failed counts for partial errors
Behavior across all signal types (traces, metrics, logs, profiles)
Correct interaction with the receiver metrics feature gate
Correct outcome attribute for partial success

All existing tests continue to pass.

Documentation

Added package-level documentation for receivererror describing partial success semantics and intended usage.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: Ady0333 / name: Aditya Shinde (194fcca)

[Ady0333]

Hello @TylerHelmuth ,

This PR adds support for partial success reporting in receiver observability metrics by introducing a receiver-specific partial error type and updating obsreport to calculate accepted and failed counts accurately.

I’d appreciate feedback on the approach and any preferred conventions before proceeding further. Thank you.

[dashpole]

@Ady0333 thanks for working this. We are still working through the design on the issue, and (FYI) there is also another PR opened regarding this: #14445. We should get agreement on the design on the issue before proceeding with the implementation.