Metadata support: Supported resolver query semantics; Iteration

[Brent Putman]

This is the first of probably several discussion items regarding
metadata support in v3.

When working on the initial conversion of the old MetadataProvider impls
to the new MetadataResolver API, one thing came to mind that I don't
recall us discussing before.

The old API's "main" method (at least for EntityDescriptor resolution)
was: EntityDescriptor getEntityDescriptor(String entityId).  In other
words, a mandatory entityId input.

In the new API, the query input is not fixed, it's a CriteriaSet (set of
Criterion).  My initial feeling was that, like in v2, an
EntityIdCriterion would be mandatory.  Then I thought, we'd better
discuss.  Did/do we have any intention of supporting queries using the
MetadataResolver API that *don't* include an EntityIdCriterion?

For example:
1) return all EntityDescriptors that have a certain role (e.g.
IDPSSODescriptor)
2) return all EntityDescriptors that have at least 1 role that supports
SAML 2 protocol
etc.

Note that all the other current existing criteria are really about
qualifying things based on RoleDescriptors, and we have a draft
RoleDescriptorResolver already (which wraps a MetadataResolver) whose
purpose is to support querying for RoleDescriptors as the output.  So
what we're really talking about here is other kinds of use cases.

I'm inclined to say no, don't support, unless we have a real use case. 
The only thing that immediately comes to mind for me would be metadata
iteration, which leads to a separate but related question.  In the new
MetadataResolver API, there is no more getMetadata() method, so there's
no way to iterate over all the metadata (as we discussed we don't even
want to explicitly expose EntitiesDescriptors). One use for the
entityId-less query would be for finding all EntityDescriptors that have
a given role, e.g. find all the IdP's, for listing in a discovery
interface.  Do we need to support this kind of iteration, and does it
need to be through the MetadataResolver interface (as opposed to another
interface)?

I *think* in Columbus we had discussed potentially having another
interface provide an API like: Iterable<EntityDescriptor> etc. 
Resolvers that can could optionally support this API also. This could be
used for the basic iteration cases.

--Brent