Result set handling bugs

[Cantor, Scott]

FWIW, I have a major check in that refactors the IdPAttribute API into
List<> instead of Set<> and made a number of adjustments to the plugins
and dependency merging helpers.

I also added back the de-dup logic to the finalize() step in the resolver,
which is just a copy of the code from V2 doing that same thing in the same
spot.

I left the filtering API as Set<> to prevent the filter from reintroducing
duplicates.

All the tests pass, but I haven't checked in so I haven't tested in my
live environment yet.

I'll wait until we talk about it, in case I'm missing something, but one
way or the other these have to be lists, no way around that.

-- Scott

On 10/16/14, 6:06 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
>
>Maybe we discussed this and I missed it, but we actually have a serious
>problem here, the IdPAttribute.getValues() method returns an unordered
>Set, but we can't do that. We have to handle relational data and that
>means ordered lists so the indexes line up. We can't de-dup that low in
>the stack, it has to be done at the end.
>
>If this is a major change, so be it, but I don't see that there's a
>choice. Rod, can you enlighten me as to the impact?
>
>We can discuss on the call tomorrow.