Feature/filter metrics v3.2

[reftel]

This adds support for measuring time for the entire request processing, and the request and response filtering steps, in addition to the current measurement of the time used by the request method itself. In addition, support is added for letting users specify the clock to be used.

No extra metrics are added for methods with @timed annotations that specify an explicit name, as it's not really clear what those extra metrics should be named, and it seems wrong to add attributes to the @timed annotation for jersey-specific concepts. Ideas for how to add the extra metrics for explicitly named methods welcome!

Corresponding PR for master: #1119

[arteam]

This looks like an interesting addition, could you explain your use case? Do you have several filters which take a lot of time to process? Or do you want to measure Jersey's overhead along with the method?

[reftel]

Sure! I'm working on some services related to handling of case folders for the Norwegian Tax Authority. This involves some rather complex data structures that can contain highly sensitive information in several places.
One of the cases where filter metrics is valuable is in an application that handles modification requests for cases. If we get a simple operation (e.g. adding a comment) on a complicated case, a filter we have for preprocessing the case to find all information that may be relevant for an authorisation decision so that we in a later stage can make an informed decision, can easily take more time than the operation itself. We also have other filters that make HTTP calls to a third-party service, so including or not including the request filter stage in the metric for the endpoint makes a big difference - our consumers care about the response time for the request as a whole, and monitoring just the time spent by the request method isn't enough.

[reftel]

Was that explanation enough? Is there anything else that we can do to progress on this feature?

[arteam]

I will look at it more one more time tomorrow and if it's OK will make a new 3.2.5 release.

[arteam]

Thank you very much for the contribution! The feature looks very useful and the implementation seems backward compatible and don't create a big performance penalty.

[arteam]

I've decided to go with this change only for 4.0.0 and keep the 3.2 branch only for bugfixes.