sdk/log: Move `Enabled` method from `FilterProcessor` to `Processor` interface

[pellared]

Move the Enabled method from the FilterProcessor interface directly into the Processor interface and remove FilterProcessor entirely.

Motivation

Currently, processors that want to support pre-evaluation of whether a record will be processed must implement a separate FilterProcessor interface. This creates additional complexity and type assertions in the SDK.

Additionally, the OpenTelemetry specification is stable LogRecordProcessor.Enabled per opentelemetry-specification#4717, which suggests this functionality could be part of the core processor contract rather than an optional extension. I think we added it as optional extension as we were not certain if/when LogRecordProcessor.Enabled is going to be stable in the specification.

Proposed Changes

Before:

type Processor interface {
    OnEmit(ctx context.Context, record *Record) error
    Shutdown(ctx context.Context) error
    ForceFlush(ctx context.Context) error
}

type FilterProcessor interface {
    Enabled(ctx context.Context, param EnabledParameters) bool
}

After:

type Processor interface {
    OnEmit(ctx context.Context, record *Record) error
    Enabled(ctx context.Context, param EnabledParameters) bool
    Shutdown(ctx context.Context) error
    ForceFlush(ctx context.Context) error
}

Pros

1. Specification alignment: Aligns with the OpenTelemetry specification as LogRecordProcessor.Enabled is being stabilized
2. Simpler API: Single interface to implement instead of two separate interfaces
3. Better discoverability: Users don't need to know about FilterProcessor - the Enabled method is part of the main interface
4. Reduced complexity: No need for type assertions to check if a Processor also implements FilterProcessor
5. Consistent behavior: All processors have the same contract regarding filtering
6. Cleaner SDK code: The Logger.Enabled implementation becomes simpler without checking for type satisfaction
7. Natural fit: Pre-evaluation of processing is a common enough concern that it belongs in the core interface
8. Similarity: This would align the Logs SDK more closely with the OpenTelemetry specification and with patterns in metrics and tracing where processing decisions are more tightly integrated into the core interfaces.

Cons

1. Breaking change: Existing Processor implementations that don't implement Enabled will break
   • Counterpoint: The Logs SDK is not stable
2. Forces all processors to implement: Even processors that don't need filtering must implement the method
   • Counterpoint: Simple default implementation (return true) is trivial
3. Not all processors need filtering: Some processors (e.g., simple exporters) may not benefit from this functionality
   • Counterpoint: Having a consistent interface simplifies the SDK and user code
4. Migration effort: Users with custom processors need to add the Enabled method
   • Mitigation: Clear migration guide

Alternative Considered

Keep FilterProcessor as is, but this maintains the current complexity and dual-interface pattern.

Related

• opentelemetry-specification#4717 - Stabilizing LogRecordProcessor.Enabled in the specification
• go.opentelemetry.io/contrib/processors/minsev - Example processor that implements FilterProcessor

---

_{Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}