gh-76984: Handle DATA correctly for LMTP with multiple RCPT

[middagj]

Conform RFC 2033, the LMTP protocol gives for each successful recipient a reply.
The smtplib only reads one. This gives problems sending more than one message
with multiple recipients in a connection. See https://bugs.python.org/issue32803

To be backwards compatible, I added a new method multi_data to support a DATA command with multiple replies. I modeled it after data and wanted to keep the error handling in the sendmail method. Because we need to close the connection once we receive a 421, I chose to yield the results instead of returning a list. Similar to the multiple RCTP solution, I only raise an Exception if all recipients fail.

I am not sure about the naming of LMTPDataError. It breaks the structure of all errors beginning with LMTP, but it is really a specific LMTP error. An alternative could be SMTPMultiDataError.

I also fixed the assertion in test_421_from_data_cmd. I think it should compare rset_count and not rcpt_count. The rcpt_count is only modified if rcpt_response is used. The purpose of the test is to be sure the method closed instead of reset.

https://bugs.python.org/issue32803

• Issue: smtplib: LMTP broken in the case of multiple RCPT #76984

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[middagj]

@picnixz what is missing to get this PR merged at some point in time?

[picnixz]

I just changed the title of the PR as it was against bpo IDs (which were moved to GH issues 3y ago I think) so I didn't look at it. I can have a look at that PR and review it though!

[picnixz]

I'll need to review more carefully this but, assuming that this is a new feature and not just a bugfix:

• This will need a What's New entry.
• The docs need some updates (if we're documenting exceptions for instance, we also need to add this new exception to the docs)

I'd treat this as a new feature as it's a behavioral change but I need to get the context and the RFC before that so this is just a preliminary review

[picnixz]

Oh and if @bitdancer has time, they can have a look at this one before me since they are more knowledgable (I don't have much time for email and http related stuff now)

[github-actions]

This PR is stale because it has been open for 30 days with no activity.