Multivalue/singlevalue distinction should be more granular

[Iizuki]

Summary

As I mentioned in #25, the singlevalue/multivalue distinction should be more granular.

Current situation

Currently you need to select singlevalued/multivalued attributes for the whole object you are getting from LDAP. The choice is made by calling the respective methods, like Record::to_record and Record::to_multi_valued_record_.

Ideal situation

We should be able to make this choice for individual attributes. It's unlikely that they're actually all multivalued.
We should get an error if a type proclaimed singlevalued actually had multiple values.

Proposed solution

Serialize everything as multivalued to the intermediary serde serpresentation and then use serde annotations to deserialize singlevalued attributes as non-list-types. I don't exactly know how to to this right now, but I presume that it's somehow possible with serde_with.

It could look something like this:

#[serde_as]
#[derive(Deserialize, Debug)
struct Foo {
  #[serde(with = "singlevalued")]
  singlevalued_attribute: String,
  // Perhaps serde_as is required.
  #[serde_as(as = "Singlevalued<_>")]
  another_singlevalued_attribute: String,
  // Options should be supported as well.
  #[serde_as(as = "Option<Singlevalued<_>>")]
  maybe_existing_singlevalued: Option<String>,
  // Multivalued would be the norm, as that's what's returned by ldap3.
  multivalued_attribute: Vec<String>,
}

We probably need to provide the Singlevalued thing by ourselves, though serde_with crate might already have something for us.

I might contribute this myself at some point.

[Iizuki]

Seems like you tackled this for string valued attributes?

[keaz]

Ahh, yes, forgot to tag you. Still working on binary values.

[Iizuki]

Using OneOrMany seems like a convenient approach 👍

[Iizuki]

What's the status here?

I was tempted to remove the unused map_to_multi_value_bin() style functions, but I decided to leave them in place as this issue is still open.