Replace custom netty event loop metrics with micrometer provided metrics

[divijvaidya]

We have added a few Netty event loop related metrics at #4675, because at that time micrometer did not support these metrics. Since then micrometer >= 1.11 version supports similar metrics but under a different namespace - micrometer-metrics/micrometer#522.

The namespace of the metrics differ in the two implementations. Hence, we will need to deprecate the old metrics (but not remove them to keep backward compatibility) and add the new ones. The table below highlights the changes in the metric names.

Metric purpose	Micrometer (micrometer-metrics/micrometer#522)	Armeria (#4675)
Pending I/O tasks waiting on an EventLoop	netty.eventexecutor.tasks.pending	<prefix>.event.loop.pending.tasks (e.g. armeria.netty.common.event.loop.pending.tasks)
Number of EventLoop threads in a group	— (not exported) (started a request to add this at micrometer-metrics/micrometer#6375)	<prefix>.event.loop.workers
Netty allocator / memory-usage gauges	netty.allocator.* (memory.used, memory.pinned, pooled.*)	Added in 7a6ddd7

[divijvaidya]

FYI, I am picking up to work on this. Will update as soon as I have a PR ready.

[divijvaidya]

There are two ways to accomplish fixing the backward compatibility:

1. We emit duplicate metrics with different names until we are ready for breaking change (at which point we will remove the old metric names) OR
2. We use Micrometer for the common metrics and add a MetricFilter such as below to change the names of metrics emitted by Micrometer to the names that align with our current names.

/**
     * This {@link MeterFilter} is used to maintain backward compatibility with the metric names introduced
     * in Issue#4675
     */
    private class MeterNameBackwardCompatibilityFilter implements MeterFilter {
        @Override
        public Meter.Id map(Meter.Id id) {
            if (id.getName().startsWith(EVENT_EXECUTOR_TASKS_PENDING.getName())) {
                id.withName(idPrefix.name("event.loop.pending.tasks"));
                id.withTags(idPrefix.tags(id.getTags()));
            }
            return id;
        }
    }

The first approach is easier to code with less surface area for bugs, at the cost of emitting duplicate metrics. The latter change is more intrusive with changes to the AbstractCloseableMeterBinder and other interfaces but is more optimized since it emits single metric. My preference is to go with the former. @minwoox thoughts?

[ikhoon]

We emit duplicate metrics with different names until we are ready for breaking change.

I prefer this one. We may announce that the metric is deprecated in the release notes, giving users time to migrate to the new metric before introducing breaking changes.

[minwoox]

Yeah, I also prefer the first one. 😉