Thoughts on configuring action-based timer reporting

[Cantor, Scott]

Checked in code to implement this for evaluation, I didn't do any performance testing for the neutral case. The overhead in the null case is an extra webflow action at the start of every flow, and a check for a missing context in the tree at entry/exit of each action.

Any number of timers can be added via script with the start and stop names supplied:

timerCtx = input.getSubcontext("net.shibboleth.idp.profile.context.TimerContext");
timerCtx.addTimer("idp.attribute.resolution",
                  "net.shibboleth.idp.profile.impl.ResolveAttributes",
                  "net.shibboleth.idp.profile.impl.FilterAttributes");                                

Right now you can only time actions, but anything inheriting from the IdP's AbstractProfileAction class is timeable, and I'll fix it to support timing OpenSAML-wrapped actions. Or we could move this down of course, it's all IdP-space right now.

We can add additional timer start/stop checks to any operations in the system if we want.

-- Scott