View attribute filtering is not compliant with the specification

[MrAlias]

The specification states the stream configuration of a view must have an allow-list of attribute keys that it will use to filter out attributes:

• A list of attribute keys (optional). If provided, the attributes that are not in the list will be ignored. If not provided, all the attribute keys will be used by default (TODO: once the Hint API is available, the default behavior should respect the Hint if it is available).

However, the opentelemetry-go implementation uses an attribute.Filter.

The non-compliance of the implementation needs to be addressed

Proposal

Update the specification to allow something like the attribute.Filter to be used for this functionality.

Having a list of attribute keys that are allowed is in the stream configuration limits the usefulness of attribute filtering. It only allows an allow-list type filtering for static pre-determined attribute keys. Having something allowed like the attribute.Filter allows for deny-lists, filtering on values, fuzzy filtering algorithms, probabilistic filtering ... It seems like users would benefit by keeping the attribute.Filter here instead of replacing it with a []attribute.Key field.

Alternatives

Replace the attribute.Filter type with []attribute.Key in the Stream.AttributeFilter field. Use these keys to filter attributes.

[MrAlias]

Related open-telemetry/opentelemetry-specification#3441

[MrAlias]

Specification PR: open-telemetry/opentelemetry-specification#3550

[MrAlias]

Adding this to the specification does not appear viable. Moving to update our implemenetation.

[MrAlias]

The resolution applied makes the fix for #3765, and likely other future fixes, impossible.

Alternative discussed in yesterdays SIG meeting:

• Add creation functions for allow and deny list attribute filters: PoC for pre-defined attribute filters #4433
• Revert the Stream type to accept an attribute.Filter

This seems like it would be in line with the specification in spirit, a user would be able to provide a slice of keys they want to allow in-line with their Stream definition. Issues raised with this yesterday:

1. The specification may need to have the work "parameter" removed from the view configuration of the stream section. It becomes less precise, but would open up this type of solution.
2. Ideally, the TC member who will review our implementation should be asked if they think this change is appropriate. We should look for their sign-off on this.

[MrAlias]

Spec update: open-telemetry/opentelemetry-specification#3680