Fix/ban transformer

[kamilernerd]

Fixes issue causing panic: runtime error: slice bounds out of range [x:x] crashing the runtime.

[KristianLyng]

I don't understand why this is needed. Why insert an empty Metric instead of the original logic which did this in-place? Was it bugged? If so: the commit message needs to explain why.

Also, this is NOT a sufficient test. It will delete data that was not banned just because it's missing either metadata OR data. There are valid use-cases of metrics missing metadata. If this logic is needed, the test needs to be far more accurate. The ban transformer needs to ONLY ban matches, not otherwise (by its judgement) invalid Metrics. We don't want a scenario where adding the ban transformer on an irrelevant term makes a container suddenly pass validation without the user understanding why.

[KristianLyng]

So reading the original PR: If the problem is slice out of bound, we should check for slices out of bound. That's easy enough. The problem is that if we ban the last metric in the original implementation we will try to append metric[n+1] where n+1 == len(metric), which is invalid. That's easy to check and avoids inserting a dummy-container we later have to find. Checking for this is a simple as checking if n+1 >= len(metric). Pseudocode:

if metrickey == len(Metric)-1 {
   c.Metrics = c.Metrics[:metrickey]
} else {
  c.Metrics = append(c.Metrics[:metrickey] , c.Metrics[metrickey+1:]
}