New label processor

[amanbrar1999]

Description:

Implementation of the Labels Processor. This processor takes key/value string pairs specified in the collector configuration file and adds them as data point labels to all metrics that pass through it.

Link to tracking Issue:

open-telemetry#1892

Testing:

Unit tests are included and manual testing was done with logging exporter to verify data point labels were added

Documentation:

README contains some basic information, with some more example configurations in testdata/config.yaml

---

Side Notes (not going to be included upstream):

When Merging into upstream this will likely be split into 3 or 4 PRs

1. Overall code structure without much logic: Factory, README, config, examples
2. Core functionality of the processor
3. Integrating the processor to the collector
4. tests (might be done within the others though)

[JasonXZLiu]

Looks good to me! Good job :DD Just a few nitpicky comments. Feel free to just ignore them if you think they're wrong.

[alvinlin123]

As discussed offline, let's move this gigantic test data to other files.

[alvinlin123]

nit: Usually comment like this is not useful as we can see what you are doing from the code quite easily. Also comment like this may start to be a lie as time goes; when other started to modify code but not the comment.

If you really think that comment like this is needed, then consider restructuring your code like the following to use method name as comment (but I don't think it's needed in your case, so following is just example).

if label, ok := findLabelByName(labels, key); ok {
   overrideExistingLabel(labels, value);
} else {
  appendNewLabel(labels, key, valye)
}

This applies to the // If it does not exist, append it comment too.

[amanbrar1999]

Makes sense to me, comments will be removed

[alvinlin123]

nit: while this comment is good, it explains what the function is doing not "how", but consider if you can use better name for the function such that you don't need to have a comment for it.

DeDuplicateAndAppend is a bit misleading here because this function is not really doing "deduplicate"; it is either overwriting or append. The code is actually overwriting the label value regardless if the label value is "duplicated" or not. So maybe a term like "Upsert" or "UpdateOrInsert" would be a better term to use.

[amanbrar1999]

now that I think about it, I agree the function name is not very representative of what it is actually doing, I will change it to "upsert" as that is a term used in other parts of the collector as well

[alvinlin123]

You can save some repetition if you have this outer loop build into deDuplicateAndAppend function. So like:

for _, dataPoint := range doubleHistogramDataPoints {
	deDuplicateAndAppend(&dataPoint.Labels, lp.cfg.Labels)
}

So basically have the deDuplicateAndAppend to deal with looping through configured labels. If you do this, the above 3 functions would have less duplicate code.

[amanbrar1999]

great idea, will do