[Suggestion] Use `nonempty` library instead of own implementation of OneOrMany

[SeseMueller]

• [x] I have looked for existing issues (including closed) about this

Feature Request

The struct OneOrMany in this file is used in many places, but is doing the same thing as the well-maintained library nonempty is doing.

Motivation

While the manual implementation is impressive, it is lacking a few things that the nonempty library does provide (Note that both structs look essentially the same). Additionally, errors in the implementation are much more likely to be caught in the library, improving the correctness guarantees somewhat.

Lastly, the library has no forced dependencies, so it wouldn't clutter the cargo file.

Proposal

Replace all instances of the OneOrMany struct with the NonEmpty struct from that library.

Drawbacks

The NonEmpty struct does not provide the specialized string deserialization, so the replacement wouldn't be trivial. But it does have a feature flag to make serialization and deserialization available.

[0xMochan]

Hey thanks for this issue! Originally, OneOrMany was introduced in a soft-manner and then expanded upon. I do agree that using a more correct implementation would be a better way for us to go about it. I'll audit that library and see if we can leverage it across out codebase.

There's also some thorns in how we currently use OneOrMany that I'm not a fan of, particularly the .map and .try_map which simplified a ton of code bc you could ensure converting between OneOrMany w/o loosing the 1-item invariant in the iterator (which afaik, isn't representable in the type system in rust due to the lack of higher-kinded types). There's also some other custom impls that might restrict us so I'll have to see what would be ergonomic and such.

Lastly, it would be a breaking change so I want to be sure it's the best path forward!