Incorrect handling of subsequent calls to Hello()

[Hsn723]

RFC 5321 Section 4.1.4 states that

An EHLO command MAY be issued by a client later in the session. If
it is issued after the session begins and the EHLO command is
acceptable to the SMTP server, the SMTP server MUST clear all buffers
and reset the state exactly as if a RSET command had been issued. In
other words, the sequence of RSET followed immediately by EHLO is
redundant, but not harmful other than in the performance cost of
executing unnecessary commands.

Prior work in #270 and #265 partially address that, but according to section 4.1.4, EHLO/HELO may be (re)sent at any time during the session. For instance, later in 4.1.4 an example is given where a new EHLO is issued after MAIL to abort an ongoing mail transaction.

The MAIL command (or the obsolete SEND, SOML, or SAML commands)
begins a mail transaction. Once started, a mail transaction consists
of a transaction beginning command, one or more RCPT commands, and a
DATA command, in that order. A mail transaction may be aborted by
the RSET, a new EHLO, or the QUIT command.