Implementing capability caching

[dequbed]

Based on this comment by @jonhoo on #243 this PR adds the ability for Client and Session to cache returned Capabilities.

Future work should try to parse (the optionally sent) Capabilities from untagged responses to EHLO, STARTTLS, and AUTHENTICATE automatically; if none are sent they should be automatically queried.

---

This change is 

[codecov]

Codecov Report

Merging #255 (04f5c9e) into main (41c5597) will decrease coverage by 0.8%.
The diff coverage is 33.8%.

Additional details and impacted files

Impacted Files	Coverage Δ
src/client.rs	91.5% <26.0%> (-1.7%)	⬇️
src/types/capabilities.rs	55.9% <56.2%> (+0.1%)	⬆️

[jonhoo]

I don't know that I believe that we shouldn't have the cache be in Connection. We can always just forcibly-reset it whenever the relevant underlying state changes (e.g., in login). What do you think?

[dequbed]

I had two arguments for not caching the capabilities in the Connection: Firstly and definitely the weaker of the two: Separation of concerns, namely doing so makes Connection more than just a very thin shim over the underlying io::{Read + Write}. Secondly and my main argument is that caching in Connection has a smaller fuck-up-protection factor for the maintainers, i.e. "us, three years older". Clearing the cache becomes an active action that needs to be thought of, and forgetting to do so is still syntactically and semantically valid code, just one that may lead to bugs in code downstream. Having the cache in Session / Client instead forces us to at least think about the cache when going from Client to Session or vice versa.

[jonhoo]

While I think that's true, I also think the current split is a foot-gun because it means we have to replicate the cache state and logic in two places. If it was on Connection, it would be in one place, which means one place to make improvements / bugfixes over time. I think I'd err on the side of simplicity here, as it'll be quite rare that we add a new way to wrap Connection. And if we do, we're likely to do so by copy-pasting an existing wrapper first.

[jonhoo]

I think the last bit here now is #255 (comment)

[bogthe]

Hi @dequbed, I really liked that you were adding support for SASL in #243. Do you have any plans to update this PR? If you're short on time, I would be happy to help getting this (and that one) merged!