Avoid creating redundant NoopMeters

[lenin-jaganathan]

Please describe the feature request.
Currently, when the register method is called it invokes the registerMeterIfNecessary and then getOrCreateMeter. getOrCreateMeter applies the meter-filters and if any of the filters reply with a MeterFilterReply.DENY then a NoopMeter is created and returned. For every MeterFilterReply.DENY we go on creating a new NoopMeter which seems unnecessary. Instead, we should have DefaultInstances created for each of the NoopMeter and the same instance should be returned.

Rationale
NoopMeter as the name suggests no-op and does nothing. So returning a default instance should be fine.

[shakuzen]

No-op meters still have a unique ID, so I'm not sure I see what optimization would make sense here. Can you elaborate?

[lenin-jaganathan]

Yeah, I have seen it. Do you know why we have Unique ID's in Noop Meters? I guess they are never added to the registries, so not sure where this ID will be useful.

[jonatan-ivanov]

I think it is used next time when you try to register the same meter that is already denied by the filter?

[lenin-jaganathan]

That's exactly the reason why I have created this issue.

When we see the meter is not accepted, we apply the noopBuilder function and immediately return this. So, the next when someone tries to create the same meter, it goes through all the meter filter chain and returns a new Noop Instance instead.

[shakuzen]

I see now. We're not adding the NoopMeters to the meterMap, so the previously created instance isn't ever returned from getOrCreateMeter. I don't remember if that was intentional or not. It could be reasonable to change that.