Fix SMTP health checks not respecting timeout

[peterwurzinger]

What this PR does / why we need it:
The cancellation token in an SMTP handshake will be passed to the initial TCP connection as well, making it respect a given timeout.
It seems like this has already been an issue for IMAP connections, as there is a Test and the same Fix for that type of checks.

Which issue(s) this PR fixes:
#1738

Does this PR introduce a user-facing change?
At least I'm not aware of any.

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• Unit tests passing
• End-to-end tests passing

[sungam3r]

Thanks. Please look into #1740 as an example of how this can be done for modern TFMs. Let's pass cancellationToken down the call tree and use overloads that accept it. Use WithCancellationTokenAsync only as a fallback for other TFMs.

[peterwurzinger]

Alright, i finally had time for that. Please have a look if that is how you wanted it to be implemented.

But allow me a few additional notes:

1. I had to leverage the CancellationToken all the way up to MailConnection.ConnectAsync as a parameter. That is not necessarily a problem, because there is then only one place to do this TFM-dance. BUT: ImapConnection is also derives from MailConnection, yet I did not touch its implementation within this PR to not mix things up. Imo it would absolutely make sense to pass the CancellationToken in IMAP connections as well.
2. It now is a binary breaking change. Since ConnectAsync accepts a CancellationToken as default parameter, it doesn't break builds, yet if only the binary would be replaced during runtime, one would see runtime errors. (Don't know if somebody would really do that and use the "raw" MailConnection , but yeah...)
3. There are quite a few places in the mail-specific check implementations, where a Cancellation token could be passed, or an async alternative could be used. e.g.

• AuthenticateAsync
• ExecuteCommand (yet I don't know if that is maybe intentional to keep commands as atomic operations)
• AuthenticateAsClientAsync

Maybe you could share your thoughts on that.

[sungam3r]

It now is a binary breaking change

It doesn't matter for now since all packages are in 7.0.0-preview state.

[peterwurzinger]

Fair enough, yes.

[sungam3r]

@peterwurzinger Finally I returned to review this one.

AuthenticateAsync
ExecuteCommand (yet I don't know if that is maybe intentional to keep commands as atomic operations)
AuthenticateAsClientAsync

Yes, I'm fine having them all with Async suffix and accepting CancellationToken. Also place ArrayPool<byte>.Shared.Return(readBuffer); under finally in ExecuteCommand.

[peterwurzinger]

Shall this be done within this PR, or shall I open a separate one? I guess it would touch not only the SMTP implementation, but also the IMAP check, therefore being probably a lot more than just fixing #1738

[peterwurzinger]

@sungam3r I opened another PR to cover those additional chores:
#1812