Add ability to filter out metric by id name

[ibilley7]

Users might want to the ability to filter out metrics that are not necessary for them to view. Created a static getMeterFilter function in MeterRegistryFactory to filter out metrics user does not want to see. Created new Property GENERAL_MICROMETER_ID_FILTERS, and filters specified via this property will be added to meter registries created in MeterInfoImpl

Closes issue #4599

[lbschanno]

This PR is failing checks because we need to specifically allow the MeterFilter class within the apilyzer configuration. You need to insert the following:

<allow>io[.]micrometer[.]core[.]instrument[.]config[.]MeterFilter</allow>

to core/pom.xml, directly below where there is a similar statement for MeterRegistry, line 301, so that we then have the following:

 <allows>
                <allow>io[.]micrometer[.]core[.]instrument[.]MeterRegistry</allow>
                <allow>io[.]micrometer[.]core[.]instrument[.]config[.]MeterFilter</allow>
                <allow>io[.]opentelemetry[.]api[.]OpenTelemetry</allow>
                ...

[DomGarguilo]

This looks pretty good. I am wondering if we should switch the filtering from a "deny list" to an "accept list" i.e. instead of defining which meters we want to filter out, we define a filter for only the meters we want to see. I don't think it makes a huge difference but might make things more intuitive or safer but I'm open to considering others opinions on this.

[ctubbsii]

Rather than provide a way to specify patterns that we turn into a MeterFilter class that we maintain, I think it would be better to be able to simply specify a MeterFilter class that the user provides, whose implementation is up to the user. We could provide a simple regex-based one as a reference.

However, the user already has the ability to construct a meter registry, with any filters they want, because they can specify a MeterRegistryFactory class that adds any MeterFilter they want on their MeterRegistry at the time their specified factory constructs it. So, I'm not sure we need to add this extra configuration at all.

Instead, since we have a LoggingMeterRegistryFactory as a reference implementation for a MeterRegistryFactory, you could just add these MeterFilter options to that factory's implementation only. I don't think this should be done as an extra feature in MetricsInfoImpl for all MeterRegistryFactory implementations the user might specify, because I think it's the responsibility of the Factory that the user provides to produce a MeterRegistry that is configured the way they want it to be.

[ctubbsii]

Instead of making the delimiter configurable, a different way of doing this, one that is more consistent with how we have set other properties, would be to support something like:

general.custom.metrics.loggingfactory.filter.exclude.1=prefix1
general.custom.metrics.loggingfactory.filter.exclude.2=prefix2
general.custom.metrics.loggingfactory.filter..exclude.3=prefix3

That way you don't have to worry about a delimiter at all.

Alternatively, make it a single regex filter:

general.custom.metrics.loggingfactory.filter.deny.regex=^(prefix1|prefix2|prefix3).*$

[ibilley7]

Today is the last day of my internship and I am returning back to school, so I would need someone else to take over this ticket if its a good enhancement to move forward with, as I won't have time to focus on it.