feat: extract micrometer support into its own module

[metacosm]

Fixes #576. This allows getting rid of mandatory micrometer dependency
if users are not interested in having metrics.

[csviri]

Made some comments on the original issue

[csviri]

I'm not against this, it makes sense. Just wonder if has that much added benefit, while we introduce an additional module. But again I'm not against this.

[lburgazzoli]

I think the split makes sense however I think we should reason a little bit more about how metrics related bits are added into the code as example for what concerns DefaultEventHandler we don't to a great job:

https://github.com/java-operator-sdk/java-operator-sdk/blob/4d36922c90c49767a355c44006fc5586fe91a967/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/DefaultEventHandler.java#L35-L44
https://github.com/java-operator-sdk/java-operator-sdk/blob/4d36922c90c49767a355c44006fc5586fe91a967/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/Operator.java#L35-L46

In the code above we are saying:

1. DefaultEventHandler is one of the possible implementation of EventHandler
2. DefaultEventHandler has a static field that is used to configure metrics
3. well, having the EventHandler interface in not very useful as we rely on a static field on DefaultEventHandler to set-up metrics.

So I wonder if instead, if metrics are enabled, then we should instantiate a InstrumentedEventHandler maybe provided by the micrometer support which IMHO, would make the addition of this new module even more meaningful (the InstrumentedEventHandler can be eventually loaded using the ServiceLoader mechanism, Quarkus could optimize things by pre-loading and configuring micrometer at build time)

[csviri]

Definitely, will take a look on that also soon. Maybe we can discuss that under a new issue, and we can discuss the design there.

What I don't like on micrometer core that is has bunch of dependencies. That is a good argument to not have it on the classpath by default.
On the other hand it's de facto industry standard, and every production system needs to have metrics monitored. So eventually everybody will use this module. And more importantly they should.

So if you insist to merge this I'm fine. Just let's think in the future if it really has the benefit, since we have to then create additional abstractions for this in core.

[metacosm]

@csviri @lburgazzoli I changed how we deal with EventMonitor, hopefully it makes more sense now… I can't really do the full clean-up I'd like to until v2, though… Let me know what you think!

[csviri]

LGTM