IdpAttribute#getValues()

[Rod Widdowson]

> What is the fix ? Providing something like addValue[s]() and
> removeValue[s]() ?

Nothing that advanced.  The setter makes an ImmutableCopy of the provided
parameter having filtered it for nulls.

Nearly all of the fixing is in the tests where

	attribute.getValues.add(new StringValue("test"));

becomes 

	attribute.setValues(Collections.singleton(new StringValue("test")));

for single value and 

	attribute.setValues(Sets.NewHashSet (new StringValue("test"),
.....));

for multiple ones. 

In the (few) iterative cases, we just insert into a separate a LinkedHashSet
in the iteration and setValues() with it at the end which of course means we
can optimize the space used.  There are no cases (except scripting, see
below) where getValues.add() isn't called immediately after the creation of
a new Attribute.

> I'm not a huge fan of add/remove either. But my main question is whether
> this affects compatibility at all in the scriptlets.

No, because the scriptlets have to present a variation of the Attribute
which matches V2 (in which getValues() returns a Collection<String>, not a
Collection<IdPAttributeValue<?>>) so we wrap the IdPAttribute in a
ScriptAttribute which 'does the right thing' (tm).  New Scripts can access
the real IdPAtribute through a new method and that will be constrained, but
that’s OK.  I actually flushed a bug in this code while testing which I'll
check in separately.

I should emphasise that this is just bring the attribute values into line
with the rest of the IdP code, as per our discussions last summer (when we
also decided that although we might like to we were *not* going to retrofit
OpenSAML)

Rod