Instrumenting metadata resolvers

[Cantor, Scott]

>  Would we want just basic request/response timing?
> That seems easy via wrapping it.  I guess could also do # of requests to
> individual domains, or for particular URIs, etc, if you can create the gauge
> name dynamically.

I haven't looked at what they're capable of measuring or what the overhead is. I don't think it's essential to do this right now, just thinking ahead.

> That's fine.  So at this point I'm mostly just wondering about the dependency
> mgmt and where any necessary custom classes would live.  Sounds like
> maybe it's lower than java-opensaml.

I've already had to do some extra work to avoid the dependency in the service classes, which are in java-support.

> Well, unless we have other ideas, I suppose we just have to bite the bullet
> and introduce the Metrics dependency.  It doesn't overwhelm me with joy,
> but I guess ultimately it's like picking any other dependency.  It's not unlike
> picking a logging library in fact (albeit without the facade abstraction that slf4j
> provides).

I don't mind avoiding the question for this release, except for the fact that there's quite a bit of interest in making sure the MDQ code includes some measurements. Using the CriteriaSet might be a compromise there to limit the amount of work needed for now.

-- Scott