Implement FromIterator for OneOrMany

[olivereanderson]

Description of change

This PR consists of a couple of small improvements to OneOrMany:

• OneOrMany<T> now implements FromIterator<T>
• The push method now behaves arguably more intuitively in the edge case of OneOrMany::Many(vec![]).

To elaborate further on the latter. The following test did not pass before this PR:

   let mut collection = OneOrMany::Many(Vec::<u32>::new());
    collection.push(42);
    assert_eq!(collection, OneOrMany::One(42));

This is not a bug, but most would probably expect the One variant to be matched when there is exactly one element in the collection. Our change should not affect the behaviour in any other cases.

Links to any relevant issues

Be sure to reference any related issues by adding fixes issue #.

Type of change

Add an x to the boxes that are relevant to your changes.

• Bug fix (a non-breaking change which fixes an issue)
• Enhancement (a non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Fix

How the change has been tested

Tested locally with cargo test.

Change checklist

Add an x to the boxes that are relevant to your changes.

• I have followed the contribution guidelines for this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• [] I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[cycraig]

Does OneOrMany currently allow instantiating an empty collection by using the OneOrMany::Many variant directly? Does this mean we allow deserializing invalid objects, such as a Presentation with no Credentials?

[olivereanderson]

Does OneOrMany currently allow instantiating an empty collection by using the OneOrMany::Many variant directly? Does this mean we allow deserializing invalid objects, such as a Presentation with no Credentials?

Yes, it is possible to do that.

EDIT:
And then it is probably also possible to deserialize Presentations with no Credentials, but such things should of course definitely be caught during validation (if this is not the case we will fix that).

[PhilippGackstatter]

Looks good to me.

The name of the type implies that it has len > 0 so perhaps it makes sense to enforce that in a future PR, if it currently allows invalid deserializations.

[olivereanderson]

The name of the type implies that it has len > 0 so perhaps it makes sense to enforce that in a future PR, if it currently allows invalid deserializations.

Note that it also has an is_empty method: https://github.com/iotaledger/identity.rs/blob/dev/identity-core/src/common/one_or_many.rs#L33

In the future we can definitely consider at least making Serialize and Deserialize fail in the case when the collection is empty, or alternatively use another kind of collection such as NonEmpty.

[cycraig]

Looks good to me! Thanks for the tests.

I don't think we use the Chore label for PRs anymore, just issues.

I think restricting OneOrMany to reject empty collections would be quite a large refactor since it would require bubbling-up errors and replacing From with TryFrom in quite a few places. I also think we need to keep a custom implementation rather than replacing it with NonEmpty for instance as the special serialization for the One variant is important.