[talk] internals: Initial API concerns and discussion on implementation

[repnop]

I wanted to bring up a discussion about various things we'll need to consider for the internal implementation and some stuff that affects the public API we'll be exposing.

1. Unsolicited notifications (RFC link)
   I'm unsure of how common unsolicited notifications are, but we should probably have some way of handling them gracefully. First thought was we can have a middle-layer task which is what actually communicates with the server and would handle any unsolicited messages, changing any internal flags (server_disconnected = true, etc) which the client would check. Alternatively, the client could try handling any unsolicited messages itself when it expects a response but I'm not sure how well that would work in practice

2. Error handling
   This one isn't too complicated I don't think, but I definitely want to avoid doing the same thing that ldap3 does which is return io::Result<LdapResult> which forces you to do action?.success()? which IMO is pretty awful. There's only a few non-error result codes in the ResultCode enum, so I think we should essentially merge other errors and error-code LdapResults into one error enum, the client should have enough context to do this.

3. Ergonomic Modify/Add/Search API arguments
   In a similar vein to the above, avoiding making ldap3's mistake of having some pretty awful and restricting function signatures is a pretty high priority for me