gh-76511: Fix email.Message.as_string() for non-ASCII message with ASCII charset

[serhiy-storchaka]

• Issue: Email parser creates a message object that can't be flattened #76511

[bitdancer]

This doesn't really describe the change very clearly. I would say something like "Fix exception in message_as_string that results when a message that claims to be in the ascii character set actually has non-ascii characters by replacing the non-ascii characters with ?, like the 'replace' parameter of encode does." Or something like that.

I don't want this comment to be a blocker, though.

[serhiy-storchaka]

Thank you for your suggestion @bitdancer.

[miss-islington-app]

Thanks @serhiy-storchaka for the PR 🌮🎉.. I'm working now to backport this PR to: 3.11, 3.12.
🐍🍒⛏🤖 I'm not a witch! I'm not a witch!

[bedevere-app]

GH-116364 is a backport of this pull request to the 3.12 branch.

[bedevere-app]

GH-116365 is a backport of this pull request to the 3.11 branch.

[asottile-sentry]

fwiw this seems to have caused a user-visible regression in django (at least) -- django/django#17979

oddly enough I don't think surrogates should have been involved at all -- the messages we're seeing were entirely utf-8-encodable and using a utf-8 charset. only internally after this series of changes between 3.11.6 and 3.11.9 they seem to have surrogates 🤔

my gut is something is wrong with this or one of the other recent unicode-related email patches and should probably be looked at. I can spend some time finding a minimal reproduction if that'd be useful