Support Sasl Bind Options

[irvingoujAtDevolution]

Support SASL bind, as per RFC 4511, Section 4.2. Now the Bind using NTLM is successful, as shown in example sasltest. Future improvement.

1. Implement stream/async stream with SSPI encrypt/decrypt
2. Kerberos should work out of the box (haven't tested yet), but if not, will be tested and fixed in future pull request

this PR is for fixing/adding sasl message support in proto crate

[irvingoujAtDevolution]

@Firstyear let me know if anything does not make sense to you. The sspi crates is a Window specific security provider, but it is not embedded into the protocol level. User could use the authentication provider of their choice, I give the example of how to use sspi-rs with SASL, and fixed the bind request/bind response Serialize/Deserialze with Sasl.

[irvingoujAtDevolution]

The workspace dependency cannot be optional, andif I add optional to proto/cargo.toml, I got this

PS C:\Users\jou\code\ldap3\proto> cargo check
warning: C:\Users\jou\code\ldap3\proto\Cargo.toml: unused manifest key: dev-dependencies.sspi.opional
    Finished dev [unoptimized + debuginfo] target(s) in 0.14s

how can I fix it?

[CBenoit]

You also need to specify a new feature to enable sspi (which is now optional): https://doc.rust-lang.org/cargo/reference/features.html

[irvingoujAtDevolution]

You also need to specify a new feature to enable sspi (which is now optional): https://doc.rust-lang.org/cargo/reference/features.html

right, optional dependency has a feature flag by default, do I still need to add an entry under [features]?

[irvingoujAtDevolution]

also

PS C:\Users\jou\code\ldap3> cargo build
error: failed to load manifest for workspace member `C:\Users\jou\code\ldap3\proto`

Caused by:
  failed to parse manifest at `C:\Users\jou\code\ldap3\proto\Cargo.toml`

Caused by:
  dev-dependencies are not allowed to be optional: `sspi`

[irvingoujAtDevolution]

looks like dev-dependencies cannot be optional, I suggest let's keep it as a regular dev-dependency

[CBenoit]

looks like dev-dependencies cannot be optional, I suggest let's keep it as a regular dev-dependency

My bad, I didn’t see it was only added as a dev-dependency. You’re right.

[Firstyear]

Oh if it's dev-dependency only then no issues :)

[Firstyear]

If @CBenoit is happy I'll merge :)

[Firstyear]

Thank you all! If you haven't already done so, please also add yourself to the CONTRIBUTORS.md file :)