Adding a `Response::from_bytes()` API

[djc]

I think this would be better API than providing raw nom parsers. I tried to implement it but ran into some snags which I briefly mentioned on Discord. Capturing here because it's probably a better venue:

If we implement a generic Response::from_bytes() API I don't think we can easily keep the Greeting and Ehlo variants
because those are really just more specific cases of Reply_lines/Other. I would be inclined to simplify Response to just be what Response::Other is now, it could provide as_greeting() and as_ehlo() methods instead that handle further parsing? The question here is if the connection state is allowed to influence parsing; IMO it's better to keep these separate where possible.

[duesee]

I think this would be better API than providing raw nom parsers.

I agree that nom should not be part of the API. Having Object::from_bytes(), or Object::decode() sounds good when it is used for different parsing entry points. Maybe even as a Decode trait to keep things consistent. But Response::from_bytes() as in "a parser for all SMTP responses" might be too generic.

If we implement a generic Response::from_bytes() API I don't think we can easily keep the Greeting and Ehlo variants because those are really just more specific cases of Reply_lines/Other. I would be inclined to simplify Response to just be what Response::Other is now, it could provide as_greeting() and as_ehlo() methods instead that handle further parsing? The question here is if the connection state is allowed to influence parsing; IMO it's better to keep these separate where possible.

I think of smtp-codec as a "layer" that can translate raw bytes into verified-to-be-sane SMTP objects. It should be possible to have a process A that only does parsing and forwards the SMTP objects to a process B that only does business logic. Process B won't have a dependency on smtp-codec and can implement all of its logic based on easy-to-consume objects.

With this in mind, the as_greeting() solution blurries this "boundary" a bit. After obtaining a response it could happen that as_greeting fails. If we want to make it so that it doesn't fail we (probably) need to parse anyway. Thus, I think it is better to eagerly parse (and verify) everything from the beginning.

This is also somehow related to #7. When we extract the types into a separate crate, we probably don't want to have any form of parsing in the types. It would somehow push us to decouple things. And this is IMO a good thing.

Hope that this makes sense? :-)