feat(views): add FilteringAttributesProcessor

[pichlermarc]

Which problem is this PR solving?

This PR is part of the work on #2592 and adds a FilteringAttributesProcessor, to fulfill the following spec requirement for view configuration:

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).

Short description of the changes

Adds a FilteringAttributesProcessor that can be passed to a View to filter attributes.

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

• Unit tests

Checklist:

• Followed the style guidelines of this project
• Unit tests have been added
• Documentation has been updated

[codecov]

Codecov Report

Merging #2733 (c49e0c2) into main (8daaddc) will decrease coverage by 0.00%.
The diff coverage is n/a.

❗ Current head c49e0c2 differs from pull request most recent head 611da39. Consider uploading reports for the commit 611da39 to get more accurate results

@@            Coverage Diff             @@
##             main    #2733      +/-   ##
==========================================
- Coverage   93.28%   93.27%   -0.01%     
==========================================
  Files         158      158              
  Lines        5434     5443       +9     
  Branches     1141     1141              
==========================================
+ Hits         5069     5077       +8     
- Misses        365      366       +1     

Impacted Files	Coverage Δ
...emetry-core/src/platform/node/RandomIdGenerator.ts	87.50% <0.00%> (-6.25%)	⬇️
...y-sdk-metrics-base/src/view/AttributesProcessor.ts	100.00% <0.00%> (ø)

[dyladan]

LGTM with a minor suggestion

[dyladan]

I would probably prefer to use something like Object.hasOwnProperty in order to avoid any weirdness with the object prototype. You would want to implement it respecting https://eslint.org/docs/rules/no-prototype-builtins like this maybe:

Suggested change

	if(allowedAttributeName in incoming){
	if(Object.prototype.hasOwnProperty.call(incoming, allowedAttributeName)){

[legendecas]

I submitted a PR to explicitly document that only own-enumerable attribute keys count.

[pichlermarc]

I updated this in the most recent commit.
Should I also make sure that the property is enumerable, or is that something we can assume at the point where attributes are processed? 🤔

[legendecas]

Probably we can use Object.keys to fetch the own-enumerable keys then filter them with the allowed names list and pick all of them at once. In this way, we also avoid the for-of loop since it is kinda slower than looping over an array since it depends on iterators.

[pichlermarc]

Thanks for the feedback. I changed it to use Object.keys instead. 🙂