Relying party parsing. Metadata providers

[Rod Widdowson]

I have just done a review of the metadata schema.  As for the relying-party
part I was explicitly looking for impedance mismatches.

The metadata schema is not nearly as clean as the other schemas and has
significant evidence of changing ideas and accretion in general.  I think
that this is a concrete demonstration of the nervousness we had in Columbus
about "Resources Good, NonResources bad" turning into "Resources Good,
NonResources Better" (or was it the other way around?).

Right now I do not foresee any issues with writing the parsers, but I'll
make the following notes.  Feel free to follow-up here or on Friday:

I have not reviewed the filters yet, I do not foresee difficulties in there
(but who knows)

I'll leave the warning about of deprecated attributes in place.  In an
extreme edge case (where a deprecated attribute and what it replaces is
present) I'll need to fail the parse.   I'll follow V2 as to whether the
deprecated values are actually listened to, but I'll make the warning
message explicit as to which is happening.

There are some more very odd edge cases which are currently not warned and
will be (e.g. failfastInitialization on the chaining provider)

The issues around constructing an HttpClient in the face of property
replacement will almost certainly lead me to building a FactoryBean for the
HttpBackedMetadata resolvers (remember this was something we wanted to
avoid).  Paradoxically, V2 doesn't use a FactoryBean.    It feels as though
it may be desirable to allow more configuration of the HTTPClient than our
current syntax allows, and I will bear that need in mind.  But it is
worthwhile remembering Brent's observation that that class is innately
hostile to spring configuration - I suspect that this may make the case for
having a FactoryBean even stronger.

The proof will be in the coding, but my current belief is that I will be
able to explicitly handle the ResourceBackedMetadataProvider by poking
inside the <Resource> and building one of the other MetadataResolvers.  The
exception is the Classpath and SVN Resources but for that there is the
ResourceBackedMetadata provider to fall back onto.  It seems unlikely that
anyone will be using classpath inside any existing IdP deployments and
improbable that they will be using SVN, is it worth issuing a warning on
these prior to removing them sometime in the future?  Indeed is it
worthwhile warning on this whole ResourceBackedMetadataProvider prior to
removing it? Whilst I'd like to think so, my instinct is that it will sit
badly with deployers to be jerked around yet again.

(Obviously) if the <Resource> definitions have a filter associated, we will
fail the parse.  Thus far and no further: if you are doing property replace
on metadata taken from SVN then you need to rethink your deployment.