SetAssert for containsExactly erroring based on sequence incorrectness

[NetAppBlueDevil]

Since Set is not a guaranteed order type of collection, I don't think this should be an error. The check should only be that the object instances can be 1 to 1 aligned with the expected values, but comparing iteration order is not valid.

It looks like SetAssert is not overriding the containsSequence as defined by AbstractCollectionAssert, to the sequence check is essentially from the collections instance in the abstract class and not the sets instance in the SetAssert.

See this as different as containsOnly for a set which would ensure only the expected objects were in the set, but would not have the additionaly 1 to one concern regarding duplicate instances (say of a string value) in the set.

Here is the error I got in my unit test (which passed on my initial checkin), so some indeterminate aspect of the set construction caused the iteration order change which made the failure on a subsequent run.

actual and expected have the same elements but not in the same order, at index 0 actual element was :
<java.lang.Deprecated>
whereas expected element was :
<javax.validation.constraints.DecimalMin>

[NetAppBlueDevil]

The above I was looking at the main branch source, which is apparently different from the 2.0M10 release. I encountered the above issue with the 2.0M10 release, which apparently doesn't have the exact source that I tried to analyze.