[processor/attributesprocessor] Add a convert action

[hughsimpson]

Description:
The attributes processor doesn't currently have support for type conversions. This can be necessary for 3rd parties that expect fields to be of a certain type (e.g. http.status_code might be received as a string but required to be an int by a service provider). This pr adds a convert action to the attributesprocessor, which would look like:

processors:
  attributes/convert:
      - key: http.status_code
        action: convert
        converted_type: int

Only very naive conversions have been included for now. There's no obvious behaviour for converting non-numeric types to numeric types (with the exception of numeric strings). For example, should [ 2 ] be 1 (length of array) or 2 (only value of singleton array)? Given that, all non-obvious values are converted to the zero value left unamended for now

Testing:
Tests added to the attribute processor for config and behaviour

Documentation:
Some copy has been added to the attributesprocessor readme to cover the new action type

[linux-foundation-easycla]

The committers are authorized under a signed CLA.

• ✅ hughsimpson (3e824c3, 0a512df, 37bd34f, 14d820d)

[pmm-sumo]

Thank you for the contribution @hughsimpson!

On the terminology part - I think that coerce is used in the context of an implicit action and in this case it's an explicit one, so perhaps casting or conversion would be more accurate?

[pmm-sumo]

@bogdandrutu @anuraaga @jpkrohling how does it relate to transform processor (as I understand we eventually want to replace attributes and resource processors with it)? Should we add such capability here and later provide similar function there?

[pmm-sumo]

@hughsimpson did another run and added few comments. Also, seems some checks are failing

[hughsimpson]

Pushed a merge because the bot said this issue was stale... 🤷 Any chance of a review from @dashpole or @dmitryax at some point? Is there something I've missed? I don't mind tidying the commit history or whatever...

Edit: oh, well I see that the release notes need updating, at least. I'm many releases behind on that front now. Will push

[hughsimpson]

Tbqh this entire switch block is redundant but I'm leaving it in for now to reduce churn on the pr

[pmm-sumo]

I am not sure why it is needed. Also, removing this block and uncommenting the test cases where you found issues leads to green tests :)

[hughsimpson]

That's because the tests didn't previously actually test anything. If you changed the expected attributes randomly they still passed (I noticed this because I had a typo in one of my tests but it still passed). This is because generateMetricData always returned a single None type metric with no attributes, so both the input and output generated the same empty data. If you would prefer, I could leave the tests as they are, but that felt kinda negligent to me

Changes which require some fixes

[hughsimpson]

Since there's now a ticket and pr to track the issues with the metrics attributesprocessor, I've reverted the test fixes in the hope that it can facilitate the process of this pr getting merged

[dmitryax]

Overall LGTM, just couple nits

[jpkrohling]

Once @dmitryax approves, I'll merge this one.

[hughsimpson]

@dmitryax please tell me this can get over the line now 😅

[dmitryax]

LGTM. just couple of nits

[hughsimpson]

@jpkrohling Think everything has been addressed now 🙏