Add support for MP Metrics 2.3

[tjquinno]

Resolves #2140

REST.request overview

Quite a few of the changes below support the REST.request optional feature, in which each JAX-RS endpoint is automatically measured by a distinct SimpleTimer metric. Here's the overview of how that's implemented:

1. The CDI extension adds a "synthetic" annotation (used only internally) to each JAX-RS endpoint.
2. The extension also registers the correct SimpleTimer metric for each endpoint.
3. At invocation-time the interceptor looks up the appropriate SimpleTimer instance and uses it to measure the work done in the intercepted method.

Summary of changes by module

metrics/metrics
Add HelidonSimpleTimer impl of new SimpleTimer metric
Update Registry with SimpleTimer-related methods
New tests for SimpleTimer

microprofile/metrics
Add infrastructure for @SimplyTimed in various classes

Add internal @SyntheticSimplyTimed; marker interface so CDI will trigger interception.
Add interceptor for above that looks up or creates the matching SimpleTimer to update.

Update CDI extension:

• Tell CDI about the synthetic annotation and its interceptor. (This allows the normal CDI mechanisms to take care of setting up the interceptor where needed.)
• Dynamically add synthetic @SyntheticSimplyTimed to each JAX-RS endpoint method so CDI will automatically invoke the corresponding interceptor.
• Record (during @ProcessAnnotatedType) and then register (during @AfterDeploymentValidation) the SimpleTimer metrics for each method with @SyntheticSimplyTimed

Add tests

tck/tck-metrics
Add dependency to include optional tests
Because MP metrics 2.3.2 uses non-standard constructs, add an ArrayParamConverter and its provider to CDI
Add CDI extension to register the converter provider
Add UrlResourceProvider as in several other TCK projects; TCK fetches deployment URI

examples/archetypes
Add config setting enabling REST.request behavior in MP quickstart example and archetype.

Add explicit config setting to disable REST.request in other examples as a reminder that the feature is there without turning it on.

docs
MP metrics guide
Update example output because REST.request metrics now appear
Add brief section describing config control of the feature
Add brief discussion of SimpleTimer and @SimplyTimed

SE metrics guide
Add brief discussion of SimpleTimer

[ljnelson]

Maybe a link here?

[tjquinno]

Sigh. I had started to include one and got distracted and forgot to. Adding it.

[ljnelson]

Dim recollection here that this is quite expensive to invoke with every call; I seem to recall some other class that can be cached statically to give you a new builder.

[tjquinno]

All of our metric implementations use the same pattern. The JSON field (somewhat misnamed) is declared this way:

static final JsonBuilderFactory JSON = 
    Json.createBuilderFactory(Collections.emptyMap());

IIRC the real performance drain was in the createBuilderFactory call but it probably would be good to review all uses of this pattern to see if we can speed things up.

[tomas-langer]

This is the way to do it. We need to cache the builder factory. JsonObjectBuilder itself is mutable and cannot be used from more than one thread (as it builds a single JSON Object).

[ljnelson]

This is probably good enough. Note that strictly speaking a JAX-RS annotation is one that is, in turn, annotated with HttpMethod. I'd probably leave this line alone anyway.

[tjquinno]

I want to make sure I understand.

I think you're suggesting that instead of iterating through the individual annotation classes {GET.class, etc.) to see if one is present on a given method we could look for HttpMethod.class`. Is that it?

Related, the @Observes @WithAnnotations clause currently lists the individual JAX-RS-related annotations (GET.class, etc.) in the method declaration. Could we also use HttpMethod.class there?