Define Syntax for, and add parsers for the ActivationCriteria inside the Attribute Resolvers

IDP-406: Modifications to Attribute-resolver schemas in support of V3 bean injectionClosed enterred

Complete except that I have to add a documentation case to explain the new attributes for attribute resolvers

I think it ultimately depends on how many built-in predicates we need to support. Clearly it's best if "custom" predicates just call out to beans, but I suppose having some kind of generic XML syntax might expand the range of custom predicates that could be built without needing to use Spring syntax.

I would note though, probably booleans will be a common need, and I don't think you could capture that this way.

Talking to Scott yesterday about something else, plus https://shibboleth.atlassian.net/browse/IDP-377#icft=IDP-377 got me thinking.

This facility is going to be widely used so making people use bean syntax is a big ask. OTOH we don't want to encumber ourselves with too much complication. It might be nice to nudge ourselves away from xsi:type as well.

So my slightly modified proposal is to keep the use of a bean reference but add a parameter and define several well known beans. In reality the bean reference becomes a factory bean. So the user sees

predicate="Shibboleth.AttributeResolver.ActiveFor"
predicateParam="http://example.org/SP/Entity http://example.com/SP/Entity"

but the parser summons up the factory bean of the provided name and sets the parameter as the (say) constructor). We could even hide the grubbiness of the name by having a few predefined names (which map to fully qualified beans) and if the lookup fails use the name as a bean name.

That provides trivial extensibilty and an easy user epxerience.

Cross reference the cases 339 340 and 341 require a Predicate<ProfileRequestContext>

It occurs to me that a bean which takes a Predicate<Predicate<ProfileRequestContext> > and a Function<ProfileRequestContext, AttributeResolutionContext> will do quite nicely.