clean_content incorrectly replaces references with markdown codeblocks, escapes

[Nephyrin]

Summary

The discord client will show e.g. `<@123456789012345>` literally, but clean_content will replace it. Similarly for \<@123...> where the escape renders it literally.

Reproduction Steps

Pass messages with various forms through clean_content and observe the official client treating them as literals:

• Escaping the opening bracket: \<@123456789012345>
• Within multiline codeblocks (```)
• Within inline codeblocks: `<@foo>`

Minimal Reproducible Code

No response

Expected Results

References that do not parse in the client should not be parsed here

Actual Results

They are

Intents

message_content, members

System Information

• Python v3.12.3-final
• discord.py v2.3.2-final
• aiohttp v3.9.5

Checklist

• I have searched the open issues for duplicates.
• I have shown the entire traceback, if possible.
• I have removed my token from display, if visible.

Additional Context

Worth noting, clean_contents is bizarre to begin with. It "prettifies" references, but also tries to escape things? See also #1911

[Nephyrin]

A note - it seems to me that there are several potentially desired transforms here, that are very tricky to get right:

Raw message to "clean message", where one is viewing roughly what they'd see on discord:
<@123> -> @bob

The inverse, clean message to raw message by looking up references (e.g. what the discord input textbox is doing in the client):
@bob -> <@123>

Escaping reference syntax in a string that should be literal:
<@123> -> \<@123>

Escaping markdown in a string that should be literal, and its inverse. (Example omitted, github markdown makes this a nightmare)

... and potentially doing something about emoji references and other types here: https://discord.com/developers/docs/reference#message-formatting

But clean_contents also, strangely, escapes things like @here? So similar to what #1911 was mentioning, it's not clear what role it should play, and it would be good to provide more functionality here in utils, since they're very tricky.

[149189]

I Would like to Work on this